[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: rsyncability of fsfs f6

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Fri, 10 Aug 2012 14:18:23 +0100

Stefan Fuhrmann wrote on Fri, Aug 10, 2012 at 13:27:59 +0200:
> On Thu, Aug 9, 2012 at 1:28 PM, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
> > Daniel Shahaf wrote on Thu, Aug 09, 2012 at 12:25:44 +0100:
> >> Does this property hold for f6 / 1.8?
> >
> > It seems to me it would work via one of two methods,
> >
> > 1) rsync --delete the $rev.* files and then reconstruct the manifest on
> > the target;
>
> Not sure what rsync will do when copying a directory.
> Assume the following sequence
>
> * rsync reads list of files in folder
> * svn propset splits a revprop pack file
> * rsync might not copy the new files but won't find the old pack file
> -> data loss?
>
> If rsync re-tries the process in that case, we won't lose data
> but must remove new pack pack files manually, if an old one
> exists. That is because it is hard to ensure that *all* new files
> have already been written.
>

Yes, I realised that post-sending: we should copy all revprop files and
then manually delete old ones on the target.

> > 2) exclude revprops/ from the rsync and just use 'svnsync copy-revprops'
> > from post-commit and post-revprop-change.
> >
> > Other options?
>
> * snapshots, if supported by the OS / file system
> * keeping the lock file open, i.e. prevent writes while rsync'ing
> (maybe during a second sync run only)
>

Good ideas, thanks.

So the bottom line is: f6 revprops are _not_ rsync'able without
additional code, but there are ways to overcome this.

> -- Stefan^2.
>
> --
> Join us this October for Subversion Live 2012 – 2 full days of
> training, networking, live demos and more! 25% off before Aug. 10th
> with discount code “earlybird.”
>
> Certified & Supported Apache Subversion Downloads:
> http://www.wandisco.com/subversion/download
Received on 2012-08-10 15:18:58 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.