Brane: Good to hear from you!
On Wed, Apr 11, 2018 at 2:57 PM, Branko Čibej <br...@apache.org> wrote: > On 11.04.2018 20:27, Doug Robinson wrote: > > 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? > > 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). > Simple enough experiment for them to try - I'll suggest it to them. Especially when I combine it with an observation made by Julian that a WC with the .svn and zero other files can be tar'd up and copied and then re-populated. If the payback is large enough then perhaps... Cheers! Doug -- *DOUGLAS B ROBINSON* SENIOR PRODUCT MANAGER T +1 925 396 1125 *E* doug.robin...@wandisco.com -- * <http://wandisco.com>* **The LIVE DATA Company *Find out more *wandisco.com <http://wandisco.com/>* <https://www.wandisco.com/welcome-live-data-world-video> * THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY AND MAY BE PRIVILEGED If this message was misdirected, WANdisco, Inc. and its subsidiaries, ("WANdisco") does not waive any confidentiality or privilege. If you are not the intended recipient, please notify us immediately and destroy the message without disclosing its contents to anyone. Any distribution, use or copying of this email or the information it contains by other than an intended recipient is unauthorized. The views and opinions expressed in this email message are the author's own and may not reflect the views and opinions of WANdisco, unless the author is authorized by WANdisco to express such views or opinions on its behalf. All email sent to or from this address is subject to electronic storage and review by WANdisco. Although WANdisco operates anti-virus programs, it does not accept responsibility for any damage whatsoever caused by viruses being passed.
