[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

svnsync backwards-compatibility with older servers (Was: Re: svn commit: r999421)

From: Jon Foster <Jon.Foster_at_cabot.co.uk>
Date: Tue, 21 Sep 2010 17:07:49 +0100


svnsync has always had locking, to prevent two svnsync processes from
writing to the same mirror at the same time. (If that happens, then the
mirror repo gets corrupted. You have to either delete the mirror repo
and resync, dump/load it, or restore from backup. Either way, there's
significant downtime).

Unfortunately, this locking has always been broken (there's a race
condition). It's impossible to fix it if the mirror server is running
<=1.6 - anyone using 1.6 needs to use an external locking program like
flock(1)*. If the mirror server is running 1.7, which has the "atomic
revprops" feature, and svnsync is also version 1.7, then the locking
will work properly.

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 really don't like option 1. I think Subversion should be reliable,
and random corruption is not good. I'd like to get rid the old, buggy
locking code.

I'm not keen on option 2 either. Silently disabling a
required-for-correctness feature seems like a really bad idea. And the
locking has always been a documented feature (even if it's never

So I guess that leaves option 3. That's not fully backwards-compatible
- you can't just drop in a 1.7 svnsync to replace a 1.6 svnsync, unless
you update the server at the same time. But I feel that it's the least
bad option.


Kind regards,


* http://linux.die.net/man/1/flock

-----Original Message-----
[snip commit that does option 1]

This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd.

If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone.

Cabot Communications Limited
Verona House, Filwood Road, Bristol BS16 3RY, UK
+44 (0) 1179584232

Co. Registered in England number 02817269

Please contact the sender if you believe you have received this email in error.


This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
Received on 2010-09-21 18:08:28 CEST

This is an archived mail posted to the Subversion Dev mailing list.