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

Re: ra_serf now passes all tests was Re: svn commit: r22796 - trunk/subversion/tests/cmdline

From: John Szakmeister <john_at_szakmeister.net>
Date: 2006-12-26 11:34:34 CET

----- Justin Erenkrantz <justin@erenkrantz.com> wrote:
[snip]

> As we discussed at the summit, one of the key advantages is that
> ra_serf would allow us to do full commit parallelization *if* the
> backend FS supported it. That's just wicked cool and would be hard to
> do within ra_dav. With multiplexed connections, if you couple ra_serf
> with a set of read-only load balanced mirrors (a la dav-mirror or
> Google Code's Bigtable backend), you get *much* better server scaling
> characteristics as well. ra_serf opens us up to dumber server-side
> caches that don't need a local repository to operate.

Gotcha. That is pretty nice.

>
> Plus, Serf is not under LGPL - which is a blocker for Subclipse moving
> to Eclipse, AIUI.
>
> So, while client-side performance is an important consideration, I
> don't view it as the only one.

Point taken. My only concern about making it the default is that it's relatively untested as compared to ra_dav. Unfortunately, I also don't see a way to make it easy for users to try ra_serf without creating multiple binaries. So I guess I'm on the fence as to whether we make it the default.

>
> Note that the one bug that I can't really do much here to fix is that
> Google Code's Project Hosting doesn't work with ra_serf. It's a known
> bug on Google's end - not much I can do within this forum to fix
> that.
> =P
>
> HTH. -- justin

Very much so. Thanks!

-John

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 26 11:34:43 2006

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.