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
the
.svn directories in the filesystem.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1142565
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-02-12 04:25:02 CET