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