Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question
up vote 0 down vote accepted

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer
Being able to use arbitrary commands on a console or in a script is not at all the same a them being presented as a filesystem. Thanks for the comment though. – Chris Phillips Dec 11 '10 at 7:00
I mean: you first clone the repo to local drive, then use cron to regularly update the export of the local drive, no need to run apache locally. – Hubert Kario Dec 11 '10 at 13:33

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.