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.
-Steve
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1142601
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-02-12 04:33:54 CET