[ snipping tons of context ... ]
Jon Foster wrote on Wed, Sep 22, 2010 at 15:56:19 +0100:
> Daniel Shahaf wrote:
> > Unwedging the mirror is not bad; if some commit were replayed twice to
> > the mirror, /then/ I would be worried. :-)
>
> FYI, it *can* replay commits twice to the mirror.
>
> Real user bug report:
> http://svn.haxx.se/users/archive-2010-01/0184.shtml
>
> My analysis of that bug report:
> http://svn.haxx.se/users/archive-2010-01/0197.shtml
>
> To recover from that, the sysadmin would have to either delete
> and remirror, dump/load, or restore from backup. On a big
> repository, that's a lot of downtime.
>
Okay; then we should document (today) that when svnsync is used with
a 1.6 server, then the admin must ensure that two instances never start
at about the same time. (unless external locking is used)
Not sure where this would go (the site, the book, the mailing lists..)
> And from Daniel's earlier mail:
> > While here, there is a similar issue in svn_client_revprop_set2(). On
> > the branch, it tries to be atomic if possible; but on trunk, it has
> > always used a racy implementation. What do you think should be done
> > in that case?
>
> This is only used for "svn propedit" and GUI equivalents, right?
>
Yes.
> I think trying to be atomic if possible (i.e. what you do on the branch)
> is the right approach. This function existed before atomic-revprops and
> the race is even documented in it's docstring. Fixing the race is a
> nice improvement.
>
> The risk of hitting the race in svn_client_revprop_set2() is small, as
> it requires two humans to edit a revprop at the same time. The
> consequences are minor too - a possibly-incorrect revprop, which can
> be easily propedited again.
>
Indeed.
> I wouldn't worry about adding a "fail if not atomic" parameter. For
> the weird usecases where people care about atomicity, there's svn_ra.
Received on 2010-09-22 18:20:58 CEST