On Mon, Aug 02, 2010 at 01:40:38PM +0100, Giulio Troccoli wrote: > > > And if you decide to use svnsync for mirroring, note that the > > way the book describes the mirroring setup is vulnerable to a > > race condition. > > Make sure to read this issue: > > http://subversion.tigris.org/issues/show_bug.cgi?id=3546 > > To avoid the problem described in issue #3546, you should > > make the mirror repository pull changes from the master via a > > cronjob, and synchronise svnsync jobs using a file lock on > > the computer hosting the mirror repository. > > Only one svnsync job must be writing to the mirror repository > > at a time, or you risk breaking sync jobs. So do not push > > revisions from the master to the mirror via the post-commit > > hook (which is what the book suggests). > > Something like the following should work from a crontab on > > Linux systems: > > 0 * * * * flock -w 60 /tmp/svnsync.lock svnsync sync > > file:///path/to/repository/mirror > > > > We're working on fixing this problem such that the way the > > book describes it will work without a race condition, but > > that work is not yet complete. > > A bit OT, I just want to check that this (the race condition) does not > apply to two svnsync processes trying to sync two different > repositories.
Unless both svnsync processes are writing to the same repository, the race condition cannot trigger. > I use svnsync to keep our DR server up-to-date. We have very few > people committing to the various repositories so it's more likely (and > still it's not that likely) that two people commit to two different > repositories than to the same one, so I just wanted to check thise > scenario with you. It has nothing much to do with when commits happen. The problem is that two svnsync processes running simultaneously (for whatever reason) can corrupt svnsync meta-data, causing subsequent syncs to fail because the actual latest revision in the repository doesn't match what svnsync expects. See here for a more detailed description of the problem: http://www.mail-archive.com/d...@subversion.apache.org/msg00265.html Stefan