You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Branko Čibej <br...@xbc.nu> on 2006/10/19 07:57:37 UTC
Making ra_serf the default for DAV
At the Summit, Justin asked what conditions had to be met before we can
make ra_serf the default for DAV, and incidentally wondered if an
official Serf release was required ...
... and also reminded us that no ASF project was willing to adopt Serf ...
All right, why not kill both stones with one bird and give Serf a home
in the Subversion repository? Our Very Own Blindiny Beautiful DAV Client.
-- Brane
P.S.: And in time, it'll probably end up in the ASF that way, heh.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Making ra_serf the default for DAV
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 10/19/06, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
> On 10/19/06, Garrett Rooney <ro...@electricjellyfish.net> wrote:
> > I'm also not comfortable with us shipping it as the default DAV
> > implementation until we get things like Digest Auth and GSSAPI working
> > at least as well as they do in Neon.
>
> So, there's a difference between shipping it and making it our default in trunk.
>
> It's kind of sitting on a chicken-and-egg requirement: if folks start
> to use it more, ra_serf will get more attention and it's more likely
> to get those features; but if we won't adopt it until it is
> feature-complete, I'm not sure I'll have the incentive to finish it up
> as it seems we're constantly playing 'fetch me a rock' with vague
> promises to switch as people add more things to my plate that I must
> do to consider switching the default in trunk.
>
> So, would we be willing to switch the default in trunk say next month?
> I'll do my best to get the Win32 stuff straightened out by then, but
> I can't commit to anything else before then. But, I really think it's
> good enough to start having this conversation.
>
> We can try it as the default for a few months, then we can then
> evaluate its stability and feature set when we're ready to consider
> starting the 1.5.x series. If we don't have all of the features we
> want by the time we start 1.5.x, then we can simply rollback the
> default to ra_dav for 1.5.x. -- justin
That seems like a reasonable path forward to me.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Making ra_serf the default for DAV
Posted by Blair Zajac <bl...@orcaware.com>.
Mark Phippard wrote:
> dglasser@gmail.com wrote on 10/20/2006 12:01:12 PM:
>
>> On 10/19/06, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
>>
>>> We can try it as the default for a few months, then we can then
>>> evaluate its stability and feature set when we're ready to consider
>>> starting the 1.5.x series. If we don't have all of the features we
>>> want by the time we start 1.5.x, then we can simply rollback the
>>> default to ra_dav for 1.5.x. -- justin
>> A big difference between this and, say, making fsfs the default in 1.2
>> was that 1.1 shipped with a "feature-complete" version of fsfs and
>> explicitly told people to try to use it, whereas the 1.4 ra_serf is
>> not feature complete and is probably not being used by anyone who
>> isn't an svn developer.
>>
>> To be really conservative, we perhaps should release 1.5 with "serf
>> works great, please try it" and if all's well, 1.6 with "serf is the
>> default".
>>
>> However, that's really slow. Maybe we could somehow get a
>> "feature-complete" ra_serf version out earlier, either by choosing to
>> backport all (compatible) ra_serf changes to 1.4.2, or by somehow
>> emphasizing that people should really really really test 1.5.0rc1 with
>> ra_serf in production-like environments.
>
> If you did the backports for 1.4.2, and offered a version of Windows
> binaries on the web site, and told people Serf is faster, you would get
> downloads and people trying it. Guaranteed.
Yes, and I would get serf and a subversion variant into into MacPorts so that we
could use it there.
Regards,
Blair
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Making ra_serf the default for DAV
Posted by Mark Phippard <ma...@softlanding.com>.
dglasser@gmail.com wrote on 10/20/2006 12:01:12 PM:
> On 10/19/06, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
>
> > We can try it as the default for a few months, then we can then
> > evaluate its stability and feature set when we're ready to consider
> > starting the 1.5.x series. If we don't have all of the features we
> > want by the time we start 1.5.x, then we can simply rollback the
> > default to ra_dav for 1.5.x. -- justin
>
> A big difference between this and, say, making fsfs the default in 1.2
> was that 1.1 shipped with a "feature-complete" version of fsfs and
> explicitly told people to try to use it, whereas the 1.4 ra_serf is
> not feature complete and is probably not being used by anyone who
> isn't an svn developer.
>
> To be really conservative, we perhaps should release 1.5 with "serf
> works great, please try it" and if all's well, 1.6 with "serf is the
> default".
>
> However, that's really slow. Maybe we could somehow get a
> "feature-complete" ra_serf version out earlier, either by choosing to
> backport all (compatible) ra_serf changes to 1.4.2, or by somehow
> emphasizing that people should really really really test 1.5.0rc1 with
> ra_serf in production-like environments.
If you did the backports for 1.4.2, and offered a version of Windows
binaries on the web site, and told people Serf is faster, you would get
downloads and people trying it. Guaranteed.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Making ra_serf the default for DAV
Posted by David Glasser <gl...@mit.edu>.
On 10/19/06, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
> We can try it as the default for a few months, then we can then
> evaluate its stability and feature set when we're ready to consider
> starting the 1.5.x series. If we don't have all of the features we
> want by the time we start 1.5.x, then we can simply rollback the
> default to ra_dav for 1.5.x. -- justin
A big difference between this and, say, making fsfs the default in 1.2
was that 1.1 shipped with a "feature-complete" version of fsfs and
explicitly told people to try to use it, whereas the 1.4 ra_serf is
not feature complete and is probably not being used by anyone who
isn't an svn developer.
To be really conservative, we perhaps should release 1.5 with "serf
works great, please try it" and if all's well, 1.6 with "serf is the
default".
However, that's really slow. Maybe we could somehow get a
"feature-complete" ra_serf version out earlier, either by choosing to
backport all (compatible) ra_serf changes to 1.4.2, or by somehow
emphasizing that people should really really really test 1.5.0rc1 with
ra_serf in production-like environments.
--dave
--
David Glasser | glasser@mit.edu | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Making ra_serf the default for DAV
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Thu, Oct 19, 2006 at 12:13:58PM -0700, Blair Zajac wrote:
> Is there any serf support in the 1.4.x branch, say for Unix systems? If
> there is, I'd like to be able to add a serf variant to the MacPorts
> subversion build. To do this, I would like to get an official tarball of
> serf, say a 0.0.1 release and make a MacPorts Portfile for it.
Yes - however, not all of the current backports are in 1.4.x. I've done some
fixes since 1.4.0 was cut that I haven't bothered to propose. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Making ra_serf the default for DAV
Posted by Blair Zajac <bl...@orcaware.com>.
Justin Erenkrantz wrote:
> On 10/19/06, Garrett Rooney <ro...@electricjellyfish.net> wrote:
>> I'm also not comfortable with us shipping it as the default DAV
>> implementation until we get things like Digest Auth and GSSAPI working
>> at least as well as they do in Neon.
>
> So, there's a difference between shipping it and making it our default
> in trunk.
>
> It's kind of sitting on a chicken-and-egg requirement: if folks start
> to use it more, ra_serf will get more attention and it's more likely
> to get those features; but if we won't adopt it until it is
> feature-complete, I'm not sure I'll have the incentive to finish it up
> as it seems we're constantly playing 'fetch me a rock' with vague
> promises to switch as people add more things to my plate that I must
> do to consider switching the default in trunk.
>
> So, would we be willing to switch the default in trunk say next month?
> I'll do my best to get the Win32 stuff straightened out by then, but
> I can't commit to anything else before then. But, I really think it's
> good enough to start having this conversation.
>
> We can try it as the default for a few months, then we can then
> evaluate its stability and feature set when we're ready to consider
> starting the 1.5.x series. If we don't have all of the features we
> want by the time we start 1.5.x, then we can simply rollback the
> default to ra_dav for 1.5.x. -- justin
Is there any serf support in the 1.4.x branch, say for Unix systems? If there
is, I'd like to be able to add a serf variant to the MacPorts subversion build.
To do this, I would like to get an official tarball of serf, say a 0.0.1
release and make a MacPorts Portfile for it.
Regards,
Blair
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Making ra_serf the default for DAV
Posted by Lieven Govaerts <sv...@mobsol.be>.
Jani Averbach wrote:
> On 2006-10-19 18:50-0400, Mark Phippard wrote:
>
>> "Daniel L. Rall" <dl...@finemaltcoding.com> wrote on 10/19/2006 05:44:58 PM:
>>
>>
>>> On Thu, 19 Oct 2006, Mark Phippard wrote:
>>>
>>> It'd be great to get some Buildbot build slaves going using serf.
>>>
>> I agree. My understanding from Paul Burba was that Buildbot is only
>> testing file:// currently. It would be nice to see it expanded to other
>> protocols, and eventually multiple server versions to test compatability
>> issues that occasionally crop up. Of course I am not volunteering :)
>>
>
> I talked with Lieven and it might be a little bit difficult do to what
> svntest was/is doing with buildbot. So, I will fire up my svntest
> system, and add ra_serf to the test setup. At some point we like to go
> over and figure out what we actually like to do with svntest/buildbot.
>
Well, it's not that difficult to add ra_svn, ra_dav or ra_serf testing.
The issue Jani refers to is that currently the buildbot master decides
which combinations the slave builds, and not the slave itself (ie.
svntest). But if you can add ra_serf to your test setup Jani that would
be cool.
I'll send a summary of the svncommit discussions concerning buildbot to
the list in the coming days, including an action list, but now I'm gonna
enjoy my three days in Manhattan.
Lieven.
PS: Daniel, thanks for volunteering, it's much appreciated ;)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Making ra_serf the default for DAV
Posted by Jani Averbach <ja...@jaa.iki.fi>.
On 2006-10-19 18:50-0400, Mark Phippard wrote:
> "Daniel L. Rall" <dl...@finemaltcoding.com> wrote on 10/19/2006 05:44:58 PM:
>
> > On Thu, 19 Oct 2006, Mark Phippard wrote:
> >
> > It'd be great to get some Buildbot build slaves going using serf.
>
> I agree. My understanding from Paul Burba was that Buildbot is only
> testing file:// currently. It would be nice to see it expanded to other
> protocols, and eventually multiple server versions to test compatability
> issues that occasionally crop up. Of course I am not volunteering :)
I talked with Lieven and it might be a little bit difficult do to what
svntest was/is doing with buildbot. So, I will fire up my svntest
system, and add ra_serf to the test setup. At some point we like to go
over and figure out what we actually like to do with svntest/buildbot.
BR, Jani
--
Jani Averbach
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Making ra_serf the default for DAV
Posted by Mark Phippard <ma...@softlanding.com>.
"Daniel L. Rall" <dl...@finemaltcoding.com> wrote on 10/19/2006 05:44:58 PM:
> On Thu, 19 Oct 2006, Mark Phippard wrote:
> ...
> > Finally, when we do produced a release tarball should we start
collecting
> > Serf/Neon information in the signatures and have any kind of
> > signature/testing requirement? Or if we declare Serf is the default,
> > require that all signatures are produced from that?
>
> It'd be great to get some Buildbot build slaves going using serf.
I agree. My understanding from Paul Burba was that Buildbot is only
testing file:// currently. It would be nice to see it expanded to other
protocols, and eventually multiple server versions to test compatability
issues that occasionally crop up. Of course I am not volunteering :)
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Making ra_serf the default for DAV
Posted by "Daniel L. Rall" <dl...@finemaltcoding.com>.
On Thu, 19 Oct 2006, Mark Phippard wrote:
...
> Finally, when we do produced a release tarball should we start collecting
> Serf/Neon information in the signatures and have any kind of
> signature/testing requirement? Or if we declare Serf is the default,
> require that all signatures are produced from that?
It'd be great to get some Buildbot build slaves going using serf.
Re: Making ra_serf the default for DAV
Posted by Mark Phippard <ma...@softlanding.com>.
justin.erenkrantz@gmail.com wrote on 10/19/2006 12:01:55 PM:
> On 10/19/06, Garrett Rooney <ro...@electricjellyfish.net> wrote:
> > I'm also not comfortable with us shipping it as the default DAV
> > implementation until we get things like Digest Auth and GSSAPI working
> > at least as well as they do in Neon.
>
> So, there's a difference between shipping it and making it our default
in trunk.
>
> It's kind of sitting on a chicken-and-egg requirement: if folks start
> to use it more, ra_serf will get more attention and it's more likely
> to get those features; but if we won't adopt it until it is
> feature-complete, I'm not sure I'll have the incentive to finish it up
> as it seems we're constantly playing 'fetch me a rock' with vague
> promises to switch as people add more things to my plate that I must
> do to consider switching the default in trunk.
>
> So, would we be willing to switch the default in trunk say next month?
> I'll do my best to get the Win32 stuff straightened out by then, but
> I can't commit to anything else before then. But, I really think it's
> good enough to start having this conversation.
>
> We can try it as the default for a few months, then we can then
> evaluate its stability and feature set when we're ready to consider
> starting the 1.5.x series. If we don't have all of the features we
> want by the time we start 1.5.x, then we can simply rollback the
> default to ra_dav for 1.5.x. -- justin
I think these are good points and this sounds like a good plan. I think
the somewhat justified fear is that even if this is made the default in
trunk there are a lot of authentication/proxy scenarios that Neon supports
that will not be tested and will surface post release.
I think that we should try to post Serf/Neon versions of the Win32
binaries. Perhaps with Serf the default and Neon in a special download.
At least it gives us options if problems surface.
Finally, when we do produced a release tarball should we start collecting
Serf/Neon information in the signatures and have any kind of
signature/testing requirement? Or if we declare Serf is the default,
require that all signatures are produced from that?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Making ra_serf the default for DAV
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 10/19/06, Garrett Rooney <ro...@electricjellyfish.net> wrote:
> I'm also not comfortable with us shipping it as the default DAV
> implementation until we get things like Digest Auth and GSSAPI working
> at least as well as they do in Neon.
So, there's a difference between shipping it and making it our default in trunk.
It's kind of sitting on a chicken-and-egg requirement: if folks start
to use it more, ra_serf will get more attention and it's more likely
to get those features; but if we won't adopt it until it is
feature-complete, I'm not sure I'll have the incentive to finish it up
as it seems we're constantly playing 'fetch me a rock' with vague
promises to switch as people add more things to my plate that I must
do to consider switching the default in trunk.
So, would we be willing to switch the default in trunk say next month?
I'll do my best to get the Win32 stuff straightened out by then, but
I can't commit to anything else before then. But, I really think it's
good enough to start having this conversation.
We can try it as the default for a few months, then we can then
evaluate its stability and feature set when we're ready to consider
starting the 1.5.x series. If we don't have all of the features we
want by the time we start 1.5.x, then we can simply rollback the
default to ra_dav for 1.5.x. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Making ra_serf the default for DAV
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 10/20/06, John Szakmeister <jo...@szakmeister.net> wrote:
>
> ----- Justin Erenkrantz <ju...@erenkrantz.com> wrote:
> [snip]
> > Yes, serfmake only works with APR > 1.0.0. If you want to use APR
> > 0.9.x, you need to use the autoconf build system instead. -- justin
>
> It'd be nice to grow support for APR < 1.0.0 for serfmake, or make the
> autoconf system work without apr sources. That may be fine for httpd
> (requiring apr sources), but I think requiring that to build a client
> is a bit steep, IMHO.
It's only required if you're building serf out of its subversion
repository. When there's finally a released version it won't be
needed.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Making ra_serf the default for DAV
Posted by John Szakmeister <jo...@szakmeister.net>.
----- Justin Erenkrantz <ju...@erenkrantz.com> wrote:
[snip]
> Yes, serfmake only works with APR > 1.0.0. If you want to use APR
> 0.9.x, you need to use the autoconf build system instead. -- justin
It'd be nice to grow support for APR < 1.0.0 for serfmake, or make the autoconf system work without apr sources. That may be fine for httpd (requiring apr sources), but I think requiring that to build a client is a bit steep, IMHO.
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Making ra_serf the default for DAV
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 10/20/06, John Szakmeister <jo...@szakmeister.net> wrote:
> Does that mean I need a specific version of APR? > 1.0.0? I couldn't find serf's requirements listed any where in the source tree. On all of my systems, I have apr-config and apu-config (no -1 in there).
Yes, serfmake only works with APR > 1.0.0. If you want to use APR
0.9.x, you need to use the autoconf build system instead. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Making ra_serf the default for DAV
Posted by John Szakmeister <jo...@szakmeister.net>.
----- Justin Erenkrantz <ju...@erenkrantz.com> wrote:
[snip]
> Use serfmake instead of the autoconf-based system.
>
> $ ./serfmake install
>
> If apr-1-config and apu-1-config aren't in your PATH, use
> --with-apr=/path/to/apr - if they are present, serfmake will just
> work(TM).
Does that mean I need a specific version of APR? > 1.0.0? I couldn't find serf's requirements listed any where in the source tree. On all of my systems, I have apr-config and apu-config (no -1 in there).
> If you are building from a checkout and using ./buildconf + ./configure
> (instead of serfmake), then you need apr and apr-util source to grab the m4
> macros - but httpd has the same source requirements. (And, when I cut a
> release, you won't need to run ./buildconf either - ./configure is
> enough.)
Got it.
> HTH. -- justin
It did! Thanks!
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Making ra_serf the default for DAV
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Thu, Oct 19, 2006 at 05:13:26PM -0400, John Szakmeister wrote:
>
> ----- Justin Erenkrantz <ju...@erenkrantz.com> wrote:
> > On Thu, Oct 19, 2006 at 06:30:48PM +0200, Stefan Kng wrote:
> > > serf also misses the progress callback neon has, which is an important
> > > feature for GUI clients. Making it the default for DAV may work ok for
> > > the command line client, but for me as the dev of TSVN I would keep
> > > using neon for that reason.
> >
> > It's not like serf is set in stone. If you can tell me what you would be
> > looking for, we might be able to add it or rather I can help you create the
> > patches. =) -- justin
>
> Along these lines, I'd like us to be able to build serf without the entire apr source tree. I'd like to use my system's apr libraries, rather than having to compile my own or rebuilding the system ones just so that I have a good source tree.
>
> You may have addressed this issue already (I haven't tried in a while), but it was a showstopper for me, and possibly for other package maintainers.
Use serfmake instead of the autoconf-based system.
$ ./serfmake install
If apr-1-config and apu-1-config aren't in your PATH, use
--with-apr=/path/to/apr - if they are present, serfmake will just work(TM).
If you are building from a checkout and using ./buildconf + ./configure
(instead of serfmake), then you need apr and apr-util source to grab the m4
macros - but httpd has the same source requirements. (And, when I cut a
release, you won't need to run ./buildconf either - ./configure is enough.)
HTH. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Making ra_serf the default for DAV
Posted by Daniel Rall <dl...@collab.net>.
On Thu, 19 Oct 2006, John Szakmeister wrote:
...
> Along these lines, I'd like us to be able to build serf without the
> entire apr source tree. I'd like to use my system's apr libraries,
> rather than having to compile my own or rebuilding the system ones
> just so that I have a good source tree.
Serf's buildconf requires APR:
--- snip ---
if [ ! -d build ]; then
$apr_src_dir/build/mkdir.sh build
fi
echo copying build files
cp $apr_src_dir/build/config.guess $apr_src_dir/build/config.sub \
$apr_src_dir/build/install.sh $apr_src_dir/build/apr_common.m4 \
$apr_src_dir/build/find_apr.m4 $apu_src_dir/build/find_apu.m4 \
$apr_src_dir/build/get-version.sh build
--- snip ---
If you have a copy of Serf which has already had its buildconf run as
appropriate for your system, you can get away with pointing Serf's
configure at apr-config and apu-config.
Re: Making ra_serf the default for DAV
Posted by Stefan Küng <to...@gmail.com>.
Justin Erenkrantz wrote:
> On Thu, Oct 19, 2006 at 06:30:48PM +0200, Stefan Kng wrote:
>> serf also misses the progress callback neon has, which is an important
>> feature for GUI clients. Making it the default for DAV may work ok for
>> the command line client, but for me as the dev of TSVN I would keep
>> using neon for that reason.
>
> It's not like serf is set in stone. If you can tell me what you would be
> looking for, we might be able to add it or rather I can help you create the
> patches. =) -- justin
neon has a callback function which provides progress information.
Basically you get information in the form of (transmitted bytes, total
bytes to transmit). While 'total bytes to transmit' is not always
available (and then simply set to 0), the 'transmitted bytes' always is.
That's the info I use in TSVN to at least show the user that *something*
is going on (i.e. I'm showing for example "transferring at 3.5kBytes/s",
if the total value is also available, I even show a progress bar).
In subversion/libsvn_ra_dav/session.c you can find out how that callback
is used (search for 'neonprogress').
I'm not sure how this would have to be done in serf though.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Making ra_serf the default for DAV
Posted by John Szakmeister <jo...@szakmeister.net>.
----- Justin Erenkrantz <ju...@erenkrantz.com> wrote:
> On Thu, Oct 19, 2006 at 06:30:48PM +0200, Stefan Kng wrote:
> > serf also misses the progress callback neon has, which is an important
> > feature for GUI clients. Making it the default for DAV may work ok for
> > the command line client, but for me as the dev of TSVN I would keep
> > using neon for that reason.
>
> It's not like serf is set in stone. If you can tell me what you would be
> looking for, we might be able to add it or rather I can help you create the
> patches. =) -- justin
Along these lines, I'd like us to be able to build serf without the entire apr source tree. I'd like to use my system's apr libraries, rather than having to compile my own or rebuilding the system ones just so that I have a good source tree.
You may have addressed this issue already (I haven't tried in a while), but it was a showstopper for me, and possibly for other package maintainers.
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Making ra_serf the default for DAV
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Thu, Oct 19, 2006 at 06:30:48PM +0200, Stefan Kng wrote:
> serf also misses the progress callback neon has, which is an important
> feature for GUI clients. Making it the default for DAV may work ok for
> the command line client, but for me as the dev of TSVN I would keep
> using neon for that reason.
It's not like serf is set in stone. If you can tell me what you would be
looking for, we might be able to add it or rather I can help you create the
patches. =) -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Making ra_serf the default for DAV
Posted by Stefan Küng <to...@gmail.com>.
Garrett Rooney wrote:
> On 10/19/06, Branko Čibej <br...@xbc.nu> wrote:
>> At the Summit, Justin asked what conditions had to be met before we can
>> make ra_serf the default for DAV, and incidentally wondered if an
>> official Serf release was required ...
>>
>> ... and also reminded us that no ASF project was willing to adopt Serf
>> ...
>>
>>
>> All right, why not kill both stones with one bird and give Serf a home
>> in the Subversion repository? Our Very Own Blindiny Beautiful DAV Client.
>
> I don't have any strong objection to moving serf into our repository,
> but I do think it should remain a separately packaged library.
> Perhaps one that we ship, but it should still be available for
> download and use by other projects.
>
> I'm also not comfortable with us shipping it as the default DAV
> implementation until we get things like Digest Auth and GSSAPI working
> at least as well as they do in Neon.
serf also misses the progress callback neon has, which is an important
feature for GUI clients. Making it the default for DAV may work ok for
the command line client, but for me as the dev of TSVN I would keep
using neon for that reason.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Making ra_serf the default for DAV
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 10/19/06, Branko Čibej <br...@xbc.nu> wrote:
> At the Summit, Justin asked what conditions had to be met before we can
> make ra_serf the default for DAV, and incidentally wondered if an
> official Serf release was required ...
>
> ... and also reminded us that no ASF project was willing to adopt Serf ...
>
>
> All right, why not kill both stones with one bird and give Serf a home
> in the Subversion repository? Our Very Own Blindiny Beautiful DAV Client.
I don't have any strong objection to moving serf into our repository,
but I do think it should remain a separately packaged library.
Perhaps one that we ship, but it should still be available for
download and use by other projects.
I'm also not comfortable with us shipping it as the default DAV
implementation until we get things like Digest Auth and GSSAPI working
at least as well as they do in Neon.
-garrett
Re: Making ra_serf the default for DAV
Posted by Mark Phippard <ma...@softlanding.com>.
Branko Čibej <br...@xbc.nu> wrote on 10/19/2006 09:41:14 AM:
> Mark Phippard wrote:
> > Being a natural troublemaker, I pointed out to the lawyers that CVS is
GPL
> > licensed, and Eclipse has always included a CVS client. They wrote
the
> > code themselves in Java, but it would be an interesting legal test of
the
> > GPL to see if you can reverse engineer a GPL product and license it
> > another way.
> >
>
> The GPL explicitly states that program output is not covered by it. The
> files in a CVS repository are the output of the CVS program, as is the
> jabber it uses as a network protocol. QED, and i hope RMS would agree.
> Otherwise all the code that was ever stored in a CVS repository is
> implicitly GPL'ed wouldn't that be fun.
Shouldn't you be adding a final recap to the svn-dev blog?
I did think I remembered reading a discussion about whether the protocol
and file formats of a GPL program was covered by the GPL or whether it
could be reverse engineered in a non-GPL program. Probably just Slashdot
nonsense though. Anyway, we are getting off topic and you have a recap to
write. :)
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Making ra_serf the default for DAV
Posted by Branko Čibej <br...@xbc.nu>.
Mark Phippard wrote:
> Being a natural troublemaker, I pointed out to the lawyers that CVS is GPL
> licensed, and Eclipse has always included a CVS client. They wrote the
> code themselves in Java, but it would be an interesting legal test of the
> GPL to see if you can reverse engineer a GPL product and license it
> another way.
>
The GPL explicitly states that program output is not covered by it. The
files in a CVS repository are the output of the CVS program, as is the
jabber it uses as a network protocol. QED, and i hope RMS would agree.
Otherwise all the code that was ever stored in a CVS repository is
implicitly GPL'ed wouldn't that be fun.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Making ra_serf the default for DAV
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 10/19/06, Lieven Govaerts <sv...@mobsol.be> wrote:
> How to build serve is documented in INSTALL on trunk, we tested it
> yesterday and the build succeeded with multiple versions of Visual Studio.
You mean 'serf', but yah, Sander, Ivan, Lieven, and I spent some time
yesterday working on this. It should be possible with
--with-serf=../path/to/serf/source to gen-make.py with the Win32
project options. (Sander had VC 2005 Pro/APR 1.x and Ivan had VC6/APR
0.9.x.)
However, there are some code issues on Win32 that we're trying to sort
out. But, now that it's somewhat possible to do the build
automagically, I'm hoping that I'll be able to build it myself and
figure out what's going wrong. (I'm currently suspicious of
apr_socket_sendv() on Win32 in APR.)
For the record, serf compiles fine against APR 0.9.x - I actually
committed Garrett's fixes back in April. And, I removed the 1.3.x
dependency on ra_serf yesterday morning. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Making ra_serf the default for DAV
Posted by Lieven Govaerts <sv...@mobsol.be>.
Mark Phippard wrote:
>> On svn trunk r20250: Allow BDB support to be optional on Win32.
>> Basically you don't add the --with-bdb param and that's it.
>>
>> This change isn't ported to the 1.4.x branch, so it'll be included in
>>
> 1.5.
>
> That is great. Is there something similar to use Serf?
>
> Mark
>
How to build serve is documented in INSTALL on trunk, we tested it
yesterday and the build succeeded with multiple versions of Visual Studio.
Lieven.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Making ra_serf the default for DAV
Posted by Mark Phippard <ma...@softlanding.com>.
Lieven Govaerts <sv...@mobsol.be> wrote on 10/19/2006 09:36:30 AM:
> > Last time I had to do this (18 months?) you had to run gen-make.py and
> > then manually edit the generated projects. Is there an easy way to do
> > this now?
> >
> On svn trunk r20250: Allow BDB support to be optional on Win32.
> Basically you don't add the --with-bdb param and that's it.
>
> This change isn't ported to the 1.4.x branch, so it'll be included in
1.5.
That is great. Is there something similar to use Serf?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Making ra_serf the default for DAV
Posted by Lieven Govaerts <sv...@mobsol.be>.
Mark Phippard wrote:
> Lieven Govaerts <sv...@mobsol.be> wrote on 10/19/2006 09:28:06 AM:
>
>
>> Mark Phippard wrote:
>>
>>> Marcus Rueckert <da...@web.de> wrote on 10/19/2006 09:14:01 AM:
>>>
>>>
>>>
>>>>> osts as well, even better.
>>>>>
>>>>>
>>>> why is lgpl a problem for them?
>>>>
>>>>
>>> *shrug* I am not a lawyer, but I guess they do not view it as
>>>
> compatible
>
>>> with the EPL. The svn code is not going to be in our repository or
>>> anything, but we do want to be able to distribute svn binaries, as we
>>>
> do
>
>>> now with Subclipse. And I guess if we want to do that, then they feel
>>>
> the
>
>>> need to approve all of it. I doubt they are going to accept the
>>>
> Sleepycat
>
>>> license either, but that wouldn't be too big of an impact for us to
>>>
> not
>
>>> include that. Other than that it is a bitch to build Win32 without
>>>
> it.
>
>> My question is slightly off topic for this discussion, but can you
>> elaborate on the 'it is a bitch to build Win32 without bdb'?
>>
>> I can build Subversion without BDB on Windows, so I'm wondering where
>> you encounter any problems.
>>
>
> Last time I had to do this (18 months?) you had to run gen-make.py and
> then manually edit the generated projects. Is there an easy way to do
> this now?
>
On svn trunk r20250: Allow BDB support to be optional on Win32.
Basically you don't add the --with-bdb param and that's it.
This change isn't ported to the 1.4.x branch, so it'll be included in 1.5.
Lieven.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Making ra_serf the default for DAV
Posted by Mark Phippard <ma...@softlanding.com>.
Lieven Govaerts <sv...@mobsol.be> wrote on 10/19/2006 09:28:06 AM:
> Mark Phippard wrote:
> > Marcus Rueckert <da...@web.de> wrote on 10/19/2006 09:14:01 AM:
> >
> >
> >>> osts as well, even better.
> >>>
> >> why is lgpl a problem for them?
> >>
> >
> > *shrug* I am not a lawyer, but I guess they do not view it as
compatible
> > with the EPL. The svn code is not going to be in our repository or
> > anything, but we do want to be able to distribute svn binaries, as we
do
> > now with Subclipse. And I guess if we want to do that, then they feel
the
> > need to approve all of it. I doubt they are going to accept the
Sleepycat
> > license either, but that wouldn't be too big of an impact for us to
not
> > include that. Other than that it is a bitch to build Win32 without
it.
> >
> My question is slightly off topic for this discussion, but can you
> elaborate on the 'it is a bitch to build Win32 without bdb'?
>
> I can build Subversion without BDB on Windows, so I'm wondering where
> you encounter any problems.
Last time I had to do this (18 months?) you had to run gen-make.py and
then manually edit the generated projects. Is there an easy way to do
this now?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Making ra_serf the default for DAV
Posted by Lieven Govaerts <sv...@mobsol.be>.
Mark Phippard wrote:
> Marcus Rueckert <da...@web.de> wrote on 10/19/2006 09:14:01 AM:
>
>
>>> osts as well, even better.
>>>
>> why is lgpl a problem for them?
>>
>
> *shrug* I am not a lawyer, but I guess they do not view it as compatible
> with the EPL. The svn code is not going to be in our repository or
> anything, but we do want to be able to distribute svn binaries, as we do
> now with Subclipse. And I guess if we want to do that, then they feel the
> need to approve all of it. I doubt they are going to accept the Sleepycat
> license either, but that wouldn't be too big of an impact for us to not
> include that. Other than that it is a bitch to build Win32 without it.
>
My question is slightly off topic for this discussion, but can you
elaborate on the 'it is a bitch to build Win32 without bdb'?
I can build Subversion without BDB on Windows, so I'm wondering where
you encounter any problems.
Lieven.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Making ra_serf the default for DAV
Posted by Mark Phippard <ma...@softlanding.com>.
Marcus Rueckert <da...@web.de> wrote on 10/19/2006 09:14:01 AM:
> > We have been in the process of moving the Subclipse project to
Eclipse.org
> > and making it an official Eclipse project. As part of this process we
> > have had to undergo a legal review of all of our code by the Eclipse
> > Foundation lawyers. Since we rely on JavaHL, this also means
Subversion
> > code has to be reviewed by the lawyers. We were told upfront there is
no
> > chance they will accept Neon because it is LGPL. I told them about
Serf,
> > which would be OK. For me, this means I'd just have to make my own
Win32
> > binary builds using Serf since that is not how the "official builds"
are
> > currently made.
> >
> > Anyway, since we would have to rely on Serf, I'd love to see it made
the
> > default so that it is getting more attention. And if we get
performance
> > boosts as well, even better.
>
> why is lgpl a problem for them?
*shrug* I am not a lawyer, but I guess they do not view it as compatible
with the EPL. The svn code is not going to be in our repository or
anything, but we do want to be able to distribute svn binaries, as we do
now with Subclipse. And I guess if we want to do that, then they feel the
need to approve all of it. I doubt they are going to accept the Sleepycat
license either, but that wouldn't be too big of an impact for us to not
include that. Other than that it is a bitch to build Win32 without it.
I guess from the Eclipse Foundation's point of view, they feel that
someone like IBM or Borland should be able to take Eclipse and make their
commercial IDE distribution without having any "surprise" license items
included.
Being a natural troublemaker, I pointed out to the lawyers that CVS is GPL
licensed, and Eclipse has always included a CVS client. They wrote the
code themselves in Java, but it would be an interesting legal test of the
GPL to see if you can reverse engineer a GPL product and license it
another way.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Making ra_serf the default for DAV
Posted by Marcus Rueckert <da...@web.de>.
On 2006-10-19 09:05:50 -0400, Mark Phippard wrote:
> Branko Čibej <br...@xbc.nu> wrote on 10/19/2006 03:57:37 AM:
>
> > At the Summit, Justin asked what conditions had to be met before we can
> > make ra_serf the default for DAV, and incidentally wondered if an
> > official Serf release was required ...
> >
> > ... and also reminded us that no ASF project was willing to adopt Serf
> ...
> >
> >
> > All right, why not kill both stones with one bird and give Serf a home
> > in the Subversion repository? Our Very Own Blindiny Beautiful DAV
> Client.
>
> FWIW, I'd like to see this happen. Here is why I care:
>
> We have been in the process of moving the Subclipse project to Eclipse.org
> and making it an official Eclipse project. As part of this process we
> have had to undergo a legal review of all of our code by the Eclipse
> Foundation lawyers. Since we rely on JavaHL, this also means Subversion
> code has to be reviewed by the lawyers. We were told upfront there is no
> chance they will accept Neon because it is LGPL. I told them about Serf,
> which would be OK. For me, this means I'd just have to make my own Win32
> binary builds using Serf since that is not how the "official builds" are
> currently made.
>
> Anyway, since we would have to rely on Serf, I'd love to see it made the
> default so that it is getting more attention. And if we get performance
> boosts as well, even better.
why is lgpl a problem for them?
darix
--
openSUSE - SUSE Linux is my linux
openSUSE is good for you
www.opensuse.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Making ra_serf the default for DAV
Posted by Mark Phippard <ma...@softlanding.com>.
"Daniel L. Rall" <dl...@finemaltcoding.com> wrote on 10/19/2006 05:44:39 PM:
> On Thu, 19 Oct 2006, Mark Phippard wrote:
> ...
> > We have been in the process of moving the Subclipse project to
Eclipse.org
> > and making it an official Eclipse project. As part of this process we
> > have had to undergo a legal review of all of our code by the Eclipse
> > Foundation lawyers. Since we rely on JavaHL, this also means
Subversion
> > code has to be reviewed by the lawyers. We were told upfront there is
no
> > chance they will accept Neon because it is LGPL. I told them about
Serf,
> > which would be OK. For me, this means I'd just have to make my own
Win32
> > binary builds using Serf since that is not how the "official builds"
are
> > currently made.
> ...
>
> Hmmm. Mark, what sort of timeframe does a Neon-replacement need to be
> available in? If it needs to happen before Subversion 1.5.0 is
> released, you may want to propose some of Justin's fixes for backport
> to the Subversion 1.4.x line.
It probably isn't urgent. I will only be providing Win32 binaries so if I
have to do something custom I will. What I expected to do was just defer
making the binaries available and come up with a way to get them via the
Subclipse site or something so that we bypass Eclipse for now. There have
been a lot of changes made in trunk for 1.5 that we want anyway. So I
might try to make 1.5 a requirement for the version we make available from
Eclipse. The really biggie for us are the copy/move improvements, but
there are several others too.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Making ra_serf the default for DAV
Posted by "Daniel L. Rall" <dl...@finemaltcoding.com>.
On Thu, 19 Oct 2006, Mark Phippard wrote:
...
> We have been in the process of moving the Subclipse project to Eclipse.org
> and making it an official Eclipse project. As part of this process we
> have had to undergo a legal review of all of our code by the Eclipse
> Foundation lawyers. Since we rely on JavaHL, this also means Subversion
> code has to be reviewed by the lawyers. We were told upfront there is no
> chance they will accept Neon because it is LGPL. I told them about Serf,
> which would be OK. For me, this means I'd just have to make my own Win32
> binary builds using Serf since that is not how the "official builds" are
> currently made.
...
Hmmm. Mark, what sort of timeframe does a Neon-replacement need to be
available in? If it needs to happen before Subversion 1.5.0 is
released, you may want to propose some of Justin's fixes for backport
to the Subversion 1.4.x line.
- Dan
Re: Making ra_serf the default for DAV
Posted by Mark Phippard <ma...@softlanding.com>.
Branko Čibej <br...@xbc.nu> wrote on 10/19/2006 03:57:37 AM:
> At the Summit, Justin asked what conditions had to be met before we can
> make ra_serf the default for DAV, and incidentally wondered if an
> official Serf release was required ...
>
> ... and also reminded us that no ASF project was willing to adopt Serf
...
>
>
> All right, why not kill both stones with one bird and give Serf a home
> in the Subversion repository? Our Very Own Blindiny Beautiful DAV
Client.
FWIW, I'd like to see this happen. Here is why I care:
We have been in the process of moving the Subclipse project to Eclipse.org
and making it an official Eclipse project. As part of this process we
have had to undergo a legal review of all of our code by the Eclipse
Foundation lawyers. Since we rely on JavaHL, this also means Subversion
code has to be reviewed by the lawyers. We were told upfront there is no
chance they will accept Neon because it is LGPL. I told them about Serf,
which would be OK. For me, this means I'd just have to make my own Win32
binary builds using Serf since that is not how the "official builds" are
currently made.
Anyway, since we would have to rely on Serf, I'd love to see it made the
default so that it is getting more attention. And if we get performance
boosts as well, even better.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org