Doug Robinson <doug.robin...@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
