Daniel Shahaf wrote on Tue, Sep 21, 2010 at 18:50:56 +0200:
> Stefan Sperling wrote on Tue, Sep 21, 2010 at 18:25:10 +0200:
> > On Tue, Sep 21, 2010 at 05:07:49PM +0100, Jon Foster wrote:
> > > So... what do we do if a 1.7 svnsync connects to a <=1.6 mirror server?
> > > Some options are:
> > >
> > > 1) It works like 1.6 - i.e. it does buggy locking that works most of the
> > > time, then one day it corrupts the mirror repo.
> > >
> > > 2) It runs without even trying to do locking. This is likely to be more
> > > obvious to the sysadmin, so they might notice it in testing.
> > >
> > > 3) It errors out with an informative message. If the user has control
> > > of the mirror server, they can upgrade it to 1.7. Alternatively, if the
> > > user doesn't need locking (e.g. they have set up external locking), they
> > > can pass --disable-locking to svnsync.
> > >
> >
> > I agree that option 3 is best. There's no point in hiding the problem
> > from the user in the name of backwards compatibility.
> >
>
> How about combining (1) and (3) --- that is, using the old locking mode
> (with its known race condition) but print a warning that the mirror
> server should be upgraded? That seems better than a fatal error for
> a condition that needs to be fixed on the server end.
>
No replies, so I've implemented this in r999868. Let me know what you
think :).
The error message says "external locking"; does the svnbook define this term?
(so the error message could link to the workaround docs)
> 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?
The docstring on trunk has always promised only a racy implementation.
I'll just leave that as-is.
Received on 2010-09-22 13:06:44 CEST