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

Re: svn co performance

From: Paul Koning <pkoning_at_equallogic.com>
Date: 2005-10-30 02:13:19 CEST

>>>>> "Noel" == Noel Yap <noel.yap@gmail.com> writes:

 Noel> On 10/29/05, Ryan Schmidt <subversion-2005@ryandesign.com>
 Noel> wrote:
>> On Oct 28, 2005, at 22:29, Paul Koning wrote: I believe what we've
>> learned on this list is that Subversion is slower than CVS for
>> checkouts but faster for most other things, and that this is an
>> acceptable trade-off because you generally make new working copies
>> infrequently but update them frequently.

 Noel> Although it's true I tend to update more frequently than
 Noel> checkout, I still checkout quite frequently since I tend to
 Noel> create new workspaces for each medium- to large-scale task.
 Noel> Doing this allows me to work independently on several tasks.
 Noel> OTOH, since I am working concurrently on several tasks, I'm
 Noel> able to do a new checkout "in the background".

That's the issue here too.

People may be working in the trunk, developing new features, only to
be interrupted by a high priority task to create a patch for branch
XYZ. Unless they happen to have a working directory for XYZ handy, or
one for PQR that they don't mind switching to XYZ (that seems to be
pretty fast) the checkout time hits them at that point.

It's certainly fair to say "we traded it off". But is there a
specific reason why it's so slow? Or is it "it's just slow and we
haven't worked on optimizing it because that's not a priority"?

I can understand either. If it's the latter, maybe I can work on it.
If the former, then probably not.


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Oct 30 02:15:26 2005

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.