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

Re: SVN "Relay"

From: 'Stefan Sperling' <stsp_at_elego.de>
Date: Mon, 2 Aug 2010 16:20:19 +0200

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/dev@subversion.apache.org/msg00265.html

Stefan
Received on 2010-08-02 16:21:10 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.