[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: Bert Huijben <rhuijben_at_sharpsvn.net>
Date: Wed, 11 Feb 2009 23:34:25 +0100

> -----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).



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