subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug Robinson <doug.robin...@wandisco.com>
Subject Re: SVN working copy split DB vs. working area
Date Fri, 13 Apr 2018 20:04:09 GMT
Philip:

Thank you for responding!

On Wed, Apr 11, 2018 at 4:08 PM, Philip Martin <philip@codematters.co.uk>
wrote:

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

Neat!  I'll mention this to the folks where DFS was just too slow.
Won't help the folks where their DFS just didn't work at all.


> > 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.
>

Assuming that atomicity on rename() is required, good point.

I hope all is going well with you.

Cheers.

Doug
-- 
*DOUGLAS B ROBINSON* SENIOR PRODUCT MANAGER

T +1 925 396 1125
*E* doug.robinson@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.

Mime
View raw message