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
> 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?
> 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:
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 :-).
Received on 2011-03-16 10:03:21 CET