[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: SVN working copy split DB vs. working area

From: Philip Martin <philip_at_codematters.co.uk>
Date: Wed, 11 Apr 2018 21:08:27 +0100

Doug Robinson <doug.robinson_at_wandisco.com> writes:

> The general setup is that they want to have a working copy on a
> Distributed File System (DFS, e.g. Lustre) and the DFS either is
> very slow (when mounted with sufficient support for SQLite) or just
> does not work due to a lack of support for SQLite - likely locking).

If SQLite locking works at all then the client-side config option

   --config-option config:working-copy:exclusive-locking=true

may help. It makes SQLite take less granular locks which improves
performance, particularly on network filesystems, by reducing the SQLite
overhead. The performance gain can be substantial.


Exclusive locking also reduces the concurrency of Subversion operations:
generally only one Subversion operation can run on a working copy at any
one time, but lots of users never notice this.

> Has this subject come up before? Is there a way to link a ".svn"
> area to the rest of the working copy? In other words, keeping the
> housekeeping area separate/split from the rest of the working copy?

It's a bit tricky. The .svn area also includes .svn/tmp/ where most
files are created before being moved to their final destination. Some
of the moves are to .svn/pristine/, within the .svn/ area, while other
moves are into the working copy itself. Moves don't generally cross
filesystem boundaries.

If we start splitting a working copy across multiple filesystems then we
may need per-filesystem temporary directories:

     /local/wc/.svn/tmp-remote -> /remote/wc/.svn-tmp/

     /remote/wc/.svn -> /local/wc/.svn/
and then we would need to make every use of the temporary directory use
the correct one based on the intended destination of the file.

Received on 2018-04-11 22:08:45 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.