Re: Any way to avoid working copy locks?

On Wed, Mar 16, 2011 at 6:02 AM, Douglas Pearson <biz_at_sunnyhome.org> wrote:
> During an "svn update" or "svn commit" my understanding of SVN is that it
> walks the local folder tree, placing some sort of lock file within each .svn
> folder.
>
> The operation is then executed and at the end, the locks are removed.  Hence
> the need for the "clean up" command if the operation crashes for some
> reason.  I assume this is done to ensure that you can't corrupt your working
> copy by running two operations at the same time on the same working copy -
> with no doubt disastrous results.  Seems reasonable.
>
> My question - is there any way to run without those local locks?
>
> We have a really big folder tree (~5GB of data and ~100,000 files in a huge
> number of folders).  Currently the time spent locking and unlocking the tree
> significantly dwarfs the time spent working on the tree (we normally are
> only changing a tiny fraction of this data).  So for automatic (non-human
> controlled) tools using SVN it would be nice to disable the locking, so
> updates and commits were faster.  For the developers out there, think
> continuous integration server.  We'd be happy to take on the risk that if we
> ran two commands at once we've blow up our working copy.  That's pretty easy
> to guarantee never happens with a single lock around the whole process.
>
> Anything we can do to get this speed up?
>
> Thanks,
>
> Doug
>
> P.S. Please include me directly in any replies.  I'm not currently
> subscribed to this list.

You are right, the locking of big trees in a Subversion working copy
is very expensive, especially on Windows and/or on network filesystems
(NFS, CIFS, ...). See this issue in the issue tracker:

http://subversion.tigris.org/issues/show_bug.cgi?id=3369 (Locking
strategy inadequate for decent Windows Performance)

(you may be able to achieve better performance on *nix operating
systems, with a filesystem that's fast with small files, and with a
fast local disk (SSD if you want the max, but a 10k rpm disk should
also be pretty good), YMMV)

The bad news is: no, you can't really disable this right now.

The good news is: this issue should go away with the upcoming 1.7
release, which contains a complete rewrite of the working copy system.
It may still take a couple of months before it's released, but it will
definitely be worth it :-).

Cheers,

-- 
Johan