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

Re: Speedup of svn on NFS?

From: Blair Zajac <blair_at_orcaware.com>
Date: Wed, 25 Jun 2008 16:37:23 -0700

Alfred Perlstein wrote:
> * Erik Huelsmann <ehuels_at_gmail.com> [080625 15:59] wrote:
>> Except that for the current implementation 'svn update' and 'svn
>> checkout' can actually share the same code, meaning that you get a
>> well-tested, stable and reliable VC. A very important property, I'd
>> say. We'd like to keep complexity of the system within bounds, meaning
>> we'd rather not add special cases. To make checkout/update faster in
>> the general case (much more worth our effort, I'd say, than a special
>> case), we do need the rewrite.
>> Thanks for your feedback!
> Is there any way to short circuit the logic there?
> Can you give me a pointer to where in the code I can start looking
> at this? For instance to get the same "fast-checkout" behavior in
> CVS it takes a 5 line patch (a few more lines to make it a command
> line option) which just short-circuits the additional code for
> the "entries" files.
> It would be very helpful and much appreciated.
> Any pointers would help.

This really isn't the direction the svn developers are heading. There's already
enough complexity in the wc code that not adding special features is something
we're trying to do.

Take a look at the next generation wc overview documents:


The next generation wc probably won't have a .svn directory per checked out
directory which should significantly improve the checkout times. Instead, there
will be one .svn directory at the top of the wc. This will give a large
performance improvement.


To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-06-26 01:37:49 CEST

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

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