On 11.04.2018 20:27, Doug Robinson wrote:
> Folks:
>
> I've now seen a request for this twice in as many days. Once from
> a customer and once from someone posting to a Subversion forum
> here:
>
> https://www.svnforum.org/forum/opensource-subversion-forums/apache-subversion-1-8-support/80218-subversion-checkout-on-distrubuted-filesytem
>
> 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).
>
> One set of folks want to accelerate by doing parallel checkouts the
> way they could do using SVN 1.6 (prior to the consolidated ".svn"
> tree). But SQLite locking will prevent that (unless I'm missing
> something).
>
> Another set of folks is ok for having the ".svn" area on a local
> file system (e.g. ext4) but want the rest of the working copy out
> there on the DFS.
>
> NOTE: both sets of folks are experienced SVN users. Both know and
> have rejected "exporting" - they want a working copy.
>
> 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?
>
> Thoughts?
One of the original design goals for the SQLite-based working copy was
that the database could be hoisted out of the working copy proper and
that multiple working copies could share the same database. However,
there has been no real work done toward that goal.
It's possible to move the .svn/wc.db database elsewhere and replace it
with a symbolic link to the original database. However, I'm not too sure
how that will help, since the SQLite journal files will still be created
in .svn/. Also, this would have to be done manually for every external
directory (which currently has its own, separate .svn/ directory).
-- Brane
Received on 2018-04-11 20:57:40 CEST