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

Re: Speeding up workspace

From: Listman <listman_at_burble.net>
Date: Wed, 11 Feb 2009 19:24:01 -0800

On Feb 11, 2009, at 2:34 PM- Feb 11, 2009, Bert Huijben wrote:

>> -----Original Message-----
>> From: Justin Case [mailto:send_lotsa_spam_here_at_yahoo.com]
>> Sent: Wednesday, February 11, 2009 1:54 PM
>> To: users_at_subversion.tigris.org
>> Subject: RE: Speeding up workspace
>> --- On Tue, 2/10/09, Bert Huijben wrote:
>>> Subversion locking
>>> strategy changes in a system that writes less locking files
>>> (8234 lock files in this case).
>> Sorry for the possibly dumb question: do you mean here the file-
>> locking
>> by SVN server for its internal needs, or the user locking a file?
>> I hope it's the first option (then I have hopes for the future)
> No, and no... yet another kind of lock.
> I'm talking about the working copy locking (nothing on the server).
> The lock
> asking you to do 'svn cleanup' if it isn't removed properly.
> Before svn update (or another operation) starts doing actual work that
> changes your working copy, it locks your working copy. It does this
> to make
> sure that no other subversion clients can update the working copy at
> the
> same time. (To avoid corruptions).
> The current working copy library does this by writing a 'lock' file
> (literally) in the .svn directory of each and every directory in your
> working copy.
> Only after it completes this first step, it starts doing the actual
> updating: Calculating what should be updated.
> In this gigantic large working copy I used for testing, this writing
> of lock
> files took +- 55 seconds.. The actual update was then just a few
> seconds and
> the removing of those 8234 files was almost instant (Not really
> measurable).

svn update is very slow with our (very large!) working copies since it
needs to
figure out whats changed before performing the update. this is where the
"shall we implement an svn edit command" discussion emanated. Perforce
keeps all changes on the server thus negating this extra sweep through
.svn directories in the filesystem.


To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-02-12 04:25:02 CET

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.