Re: SVN working copy split DB vs. working area

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.

  https://sqlite.org/pragma.html#pragma_locking_mode

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/
     /local/wc/.svn/pristine/
     /local/wc/.svn/tmp-local/
     /local/wc/.svn/tmp-remote -> /remote/wc/.svn-tmp/

     /remote/wc/
     /remote/wc/.svn -> /local/wc/.svn/
     /remote/wc/.svn-tmp-remote/
  
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.

-- 
Philip