[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 14:31:53 +0200

On Mon, Aug 02, 2010 at 07:50:49AM -0400, Nico Kadel-Garcia wrote:
> On Mon, Aug 2, 2010 at 7:41 AM, Tennebø Frode
> <frode.tennebo_at_saabgroup.com> wrote:
> >> Ok, but that's not what i we at work. The local svn will be a
> >> "working copy"
> >> of the external svn. In fact, no user have to use the
> >> external svn if there's a local svn. The goal of this is the
> >> limit the access to the WAN.
> >
> > In that case the WAN repository can be looked on as a mirror/off-line backup of the LAN repository.
> >
> > You could use rsync to keep an up-to-date mirror on the WAN while the LAN is the active server.  You need to set up an svn installation on the LAN, rsync (or some other form of copy) the initial repository from the WAN server to the LAN server.  All uses now use the LAN repository.  Some cron-job automatically rsyncs the LAN repository back to the WAN server.
> Only if the rsync is done as part of a post-commit operation:
> otherwise, what are "atomic" operations for the Subversion repository
> may be duplicated when only partially complete, and chaos may ensue.

No. That's bad advice. Running rsync from the post-commit hook won't
magically make the copy operation atomic.

rsync will never be able to create a consistent snapshot of a live
Subversion repository. Use rsync only on repositories that are known
to be consistent and that no commits or revprop edits are being made to.

Use 'svnadmin hotcopy' to create a copy of a repository that is consistent
from Subversion's point of view. There is no other repository copying
tool that can guarantee a consistent repository snapshot.
Then mirror the hotcopy with any tool of your liking.

Another way of doing it is dump/load. That will also be atomic,
but won't copy hooks and configs, only stuff beneath the db/ directory.
Making a hotcopy is much faster than creating a dump of the entire repository.

Additionally, creating incremental dumps of revisions from within the
post-commit hook is a good way of getting a backup of each revision in
virtually real time. In case of desaster, you can use these partial dumps
to fill up your backup repository to the last committed revision (or at
least very close to there). Note that a fresh full dump/hotcopy is required
every now and then if you allow people to change revprops (e.g. svn:log).

You can also load the incremental dumps of each revisions on your
repository mirror. This achieves the same effect as svnsync.

Istace, just to make sure you've understood this: You need to have
one repository which people commit to. You can create a mirror repository,
but the mirror should only be used for read-only operations.
You cannot write to the mirror and expect the changes reach the
master repository. Subversion doesn't work that way.
See also this section of the book:

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:
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.

Received on 2010-08-02 14:32:42 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.