Svnsync regularly failing and keeping lock

[Ben K <be...@gmail.com>]

Hi there,

I have two svn servers set up in a master-slave mirroring arrangement, using
HTTPS/SVNDav as the transport mechanism. The underlying link is an IPSEC
tunnel that links us in behind the firewall of the main part of the
organisation. I'm not sure of the link's overall reliability but it has been
a little flakey in the past and the latency is fairly high. It's also not
uncommon for large commits ~50MB to occur.

My problem is that fairly frequently, as in about once a week, svnsync
fails, and keeps the lock. All svnsync syncs then fail until I manually
delete the lock using propdel.

Svnsync is run as part of a post-commit hook, and also in the
post-revpropchange hook. The master server is in our local office and runs
subversion 1.6.12. The slave is in the main organisation office (on a
different continent) and runs 1.6.6. Both are configured with Apache using
https and SVNDav. I have also configured long server and https timeouts
(~50mins!) and turned of SVNPathAuthz, all in aid of fixing these sync
failures. Increasing the timeouts reduced the frequency of the failures from
around daily to around weekly.

Has anyone encountered similar to this? Is there anything I can do to get
svnsync working reliably? In its current implementation it is useless for my
purposes.

Also, I'm aware that there are some race conditions inherent in svnsync, but
I have checked the failure times and they don't seem to be correlated with
eg, two commits going in very close together. Does anyone have any guesses
at what might be causing this problem?

Re: Svnsync regularly failing and keeping lock

[Stefan Sperling <st...@elego.de>]

On Tue, Oct 26, 2010 at 12:18:10PM +1100, Ben K wrote:
> Hi there,
> 
> I have two svn servers set up in a master-slave mirroring arrangement, using
> HTTPS/SVNDav as the transport mechanism. The underlying link is an IPSEC
> tunnel that links us in behind the firewall of the main part of the
> organisation. I'm not sure of the link's overall reliability but it has been
> a little flakey in the past and the latency is fairly high. It's also not
> uncommon for large commits ~50MB to occur.
> 
> My problem is that fairly frequently, as in about once a week, svnsync
> fails, and keeps the lock. All svnsync syncs then fail until I manually
> delete the lock using propdel.
> 
> Svnsync is run as part of a post-commit hook, and also in the
> post-revpropchange hook. The master server is in our local office and runs
> subversion 1.6.12. The slave is in the main organisation office (on a
> different continent) and runs 1.6.6. Both are configured with Apache using
> https and SVNDav. I have also configured long server and https timeouts
> (~50mins!) and turned of SVNPathAuthz, all in aid of fixing these sync
> failures. Increasing the timeouts reduced the frequency of the failures from
> around daily to around weekly.
> 
> Has anyone encountered similar to this? Is there anything I can do to get
> svnsync working reliably? In its current implementation it is useless for my
> purposes.
> 
> Also, I'm aware that there are some race conditions inherent in svnsync, but
> I have checked the failure times and they don't seem to be correlated with
> eg, two commits going in very close together. Does anyone have any guesses
> at what might be causing this problem?

The locking has a known race condition.
See http://subversion.tigris.org/issues/show_bug.cgi?id=3546
and make sure to read the linked email threads.

This will be fixed in 1.7.

You need to synchronise svnsync instances manually until this problem
is fixed. You should run all svnsync instances on the same host, and
use tools like flock or lockfile to synchronise them via a file lock.