[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: Steve Bakke <steven.bakke_at_amd.com>
Date: Wed, 11 Feb 2009 22:32:45 -0500

On Feb 11, 2009, at 5:34 PM, 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).
> Bert

On a somewhat related subject, we have found the same performance
issue with
respect to actual file locking and unlocking for files with needs-
lock. If
somebody tries to do big checkin/checkout where we run 'svn lock' or
'svn unlock'
with lots of files, it takes a really long time. Part of the problem
there is that
the server doesn't use a lock database (it would be nice if it
did :^) , but instead
creates one file for each individual file lock. It also does the
same within
the working copy. Combine this with NFS mounted disks and you have a
really slow operation.



To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-02-12 04:33:54 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.