[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: should we really ship serf as default for 1.7? (was: Re: serf and sourceforge.net don't get along)

From: Mark Phippard <markphip_at_gmail.com>
Date: Fri, 24 Jun 2011 09:22:00 -0400

On Fri, Jun 24, 2011 at 9:06 AM, Stefan Sperling <stsp_at_elego.de> wrote:

> I am still uneasy about this.

Same here.

> Given the number of issues that have been filed against ra_serf recently,
> and issues that I've personally been running into when using it (all
> reported to dev@), I am still not convinced that ra_serf is stable
> enough to be the default for 1.7.
> I think we should still give it some more time to mature, and expose it to
> more testing on a variety of platforms by encouraging users to try it out.

I agree

> After all, they will get a performance gain if they use it.
> So we could use that as an incentive.

That is just it .. they won't. Other than merge, I am not aware of
any other part of SVN that is faster with Serf. There are some things
that are about the same as Neon but others where it is significantly


I still hold out hope that there will be some future version of SVN
where we have a centralized pristine store for all your working
copies, and a Serf checkout/update could avoid downloading files that
are in the local cache. That is about the only way I can see the
current approach Serf uses being a benefit. I agree with Ivan that we
should probably just change Serf to use the single large REPORT
request like Neon. This should make it perform the same (or else
reveal problems in the Serf library) and it would solve the other
concerns I have with Serf.

> The responsible thing to do here is to favour stability over performance.
> Sure, we cannot get rid of all the bugs before release, and the bugs
> will be fixed earlier if ra_serf gets more exposure. But it would be
> a disservice to our users if we released it as the default RA mechanism
> if it isn't as stable as ra_neon.
> Because the http-library is a client-side configuration setting,
> some organisations would be having a very hard time getting all
> of their users to use neon in case they run into problems with serf.

Whether we make it the default or not, I have doubts that the
packagers that provide SVN binaries will allow it to be the default.
I plan to produce the CollabNet binaries with Neon as default. Ivan
plans to do the same for VisualSVN. I cannot imagine Stefan is going
to allow TortoiseSVN to use Serf as default as long as it is less
stable and slower than Neon. I believe Bert is going to do the same
for SharpSVN. I do not know what the distros will do, but when they
start getting bug reports I would not be surprised to see them make
the same changes.

SIDEBAR: would it be possible to change svn --version so that it
indicates which module will be used by default (if there is no
http-library defined)? This could become useful if we stick with the
current approach.

Mark Phippard
Received on 2011-06-24 15:22:31 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.