Home / server / Questions / 211267
Accepted
Chris Phillips
Asked: 2010-12-11 04:53:51 +0800 CST

how best to replicate the *contents* of a subversion repository? svnsync or rsync?

  • 772

I'm working in an environment that is using a subversion server in a central location, which needs to feed its contents out to 4 different environments (prod, test etc...) Within these environments we do not need subversion functionality at all, merely to be able to access the contents of all /tags/ held within the repo by http and local filesystem.

To do this, we have two possible approaches:

1) subversion mirrors in all environments, updated using svnsync and then made available within each location via svn -> web_dav_svn -> davfs (FS access here) -> apache (HTTP access here)

2) svn export of /tags in a central location and then rsyncing the files out to the other locations, possibly after having hardlinked the previously exported file structure.

Whilst option 1 seems "slicker" in many ways (although going through apache twice???) it pushes lots of the risk down towards a live running environment, rather than keeping it back in the central location, which is essentially "offline" insofar as it never being used in the running of these environments. I'd also be concerned about putting a pretty much disposable and ignored fuse project like davfs so deep into the project. Rsync is boring and stable, and seeing as all we want is file access under our own terms, we can get that with a really basic and reliable toolset.

Any thoughts really appreciated.

apache-2.2 svn rsync

4 Answers

  1. The post-commit hook can work but it leads to possible corruption if there is write activity in the middle of the rsync. Also the local updates would be efficient but it would not guarantee a pristine build from each tag as there could be local changes introduced.

    You may want to consider a commercial product such as Subversion MultiSite which will keep an exact replica of the repositories at each location. These local replicas are updated automatically as changes are made and provide LAN performance at each node.

    • 1
  2. Best Answer

    Your instincts are correct. Option 1 seems to introduce a lot of complexity for relatively little gain.

    Option 2 would be easy to implement with a post-commit hook that updates a working copy of the repository and then uses rsync to push the repository to the necessary destinations. Updating a local working copy -- rather than using svn export -- will be much more efficient if your repository is large.

    • 0

  3. 1) subversion mirrors in all environments, updated using svnsync and then made available within each location via svn -> web_dav_svn -> davfs (FS access here) -> apache (HTTP access here)

    You don't need to run apache to have access to svn repository, especially when only one user will have access to it. Repository can be accessed by file:// protocol if it is stored on local drive.

    • 0

  4. Using svnsync may be complex, but once setup, you'll have to rarely deal with. About the only issue I've ran into using svnsync in multiple locations is the occasional svnsync lock that doesn't release which can be quickly fixed and then everything is once again up to date quickly. I'd have it happen about once or twice a year with three sync'd servers of the central server.

    The other advantage of svnsync, if you do need the other code, its there. You don't need to go through another whole process of setting things up to get the additional content.

    And the last, but probably the best reason for multiple svnsync locations, ready to go fail over if your central repository takes nose dive the hard and unrecoverable way.

    • 0