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

Re: svnadmin hotcopy --incremental

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Sat, 19 Feb 2011 12:33:08 +0200

Philip Martin wrote on Sat, Feb 19, 2011 at 10:30:17 +0000:
> Philip Martin <philip.martin_at_wandisco.com> writes:
>
> > Daniel Shahaf <d.s_at_daniel.shahaf.name> writes:
> >>
> >> Either method would need to account for old-revprop changes and for 'svn
> >> lock' locks.
> >
> > Unless we start recording some sort of history for revprops the only
> > option for svnsync is to resend all revprops, hotcopy has more options.
>
> As you know, hotcopy gets locks wrong at present (issue 3750). I've
> just thought of another thing to add to that issue but tigris.org is
> down so I'm recording it here:
>
> hotcopy currently copies revs then locks. Nothing prevents the source
> adding a rev and a lock after hotcopy has copied revs and before it
> copies locks. That means the copy could have a lock on a file that does
> not exist in the copy. I'm not sure there is any copying order we can
> use that will avoid the problem, we may need to add a post-copy step to
> audit the locks.
>

Or we could start recording locks in the revprops storage...

e.g., if I lock a file FOO with HEAD=N, then we set an internal revprop
on rM (where rM is when FOO_at_N's noderev was created). It wouldn't be
visible as a revprop outside of the FS. Not sure on the details.

I need to think more about this.

> --
> Philip
Received on 2011-02-19 11:38:16 CET

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.