Thanks for the responses and good to know this is an issue that's being worked on.
We'll look forward to 1.7 eagerly! Dou On Wed, Mar 16, 2011 at 2:02 AM, Johan Corveleyn <jcor...@gmail.com> wrote: > On Wed, Mar 16, 2011 at 6:02 AM, Douglas Pearson <b...@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 >
