You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Daniel Shahaf <d....@daniel.shahaf.name> on 2013/02/09 14:28:02 UTC

fsfs.conf knob to have merge() fail rather than automagically rebase Re: Discrepancies in svn mirror created with svnsync

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.

Re: fsfs.conf knob to have merge() fail rather than automagically rebase Re: Discrepancies in svn mirror created with svnsync

Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Stefan Sperling wrote on Sat, Feb 09, 2013 at 21:19:35 +0100:
> On Sat, Feb 09, 2013 at 03:28:02PM +0200, Daniel Shahaf wrote:
> > 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.
> 
> If it's recommended, why not have 'svnsync init' tweak the config file
> accordingly?

Because it works over libsvn_ra.

> And we could take this one step further by hiding the flag
> somewhere in the repository instead of putting it in the config file.

Sure, we could move the config file to a $REPOS_DIR/db/../foo.conf, or
an r0 revprop that FS backends be required to respect, etc.  Not sure
what would be the best place.

Re: fsfs.conf knob to have merge() fail rather than automagically rebase Re: Discrepancies in svn mirror created with svnsync

Posted by Stefan Sperling <st...@elego.de>.
On Sat, Feb 09, 2013 at 03:28:02PM +0200, Daniel Shahaf wrote:
> 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.

If it's recommended, why not have 'svnsync init' tweak the config file
accordingly? And we could take this one step further by hiding the flag
somewhere in the repository instead of putting it in the config file.