Philip Martin wrote on Sat, Feb 19, 2011 at 10:30:17 +0000: > Philip Martin <philip.mar...@wandisco.com> writes: > > > Daniel Shahaf <d...@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@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
