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.
Received on 2010-10-26 12:58:37 CEST