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 <jcorvel_at_gmail.com> wrote:
> 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
>
Received on 2011-03-16 22:20:06 CET