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.
