Andreas Mohr wrote on Sat, Feb 09, 2013 at 11:31:07 +0100:
> Hi,
>
> On Fri, Feb 08, 2013 at 03:45:29PM +0100, Stefan Sperling wrote:
> > I cannot tell you what happened here and why the revisions in the
> > mirro are empty. That sure is concerning.
> >
> > However there are known race conditions in svnsync in Subversion 1.6.
> > See http://subversion.apache.org/docs/release-notes/1.7.html#atomic-revprops
> >
> > So you should definitely wrap svnsync in a tool like lockfile (part of
> > procmail), or upgrade to 1.7.
>
> Note that directory creation/removal are the only FS mechanism which is
> guaranteed to be atomic, on UNIX (POSIX?) at least.
> Thus if lockfile isn't available/installable, as a manual mechanism
> you could fetch a tempfile name (obviously to be globally used by *all*
> svnsync script users!), and use that name to create a directory,
> run svnsync on success and then remove it.
> (or probably better use a static GUID value in the directory name)
>
> Be careful about "solutions" other than lockfile - some of these appear to be
> terribly unsafe (some newer Ubuntu-introduced "atomic locking" package
> comes to mind - which then executes anyway after a measly timeout!).
>
> Andreas Mohr
Under the commit finalization lock, if the txn-being-committed's base
revision is older than the current HEAD, by default the code will commit
it anyway provided that no conflicting changes were made in the interim.
I wonder if it would be a good idea to have a fsfs.conf knob that tells
the code to just give up if {txn's base revision} != {current HEAD}.
Then that knob would be recommended to be set on every repository which
is an svnsync slave repository.
Daniel
P.S. "merge() in the subject has absolutely no relation to 'svn merge';
it's the name of an internal FS function.
Received on 2013-02-09 14:28:51 CET