subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philip Martin <>
Subject Re: SVN working copy split DB vs. working area
Date Wed, 11 Apr 2018 20:08:27 GMT
Doug Robinson <> 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.


View raw message