Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I am currently looking into the best way to set up an SVN mirror. I currently see three possibilities all with their own drawbacks:

  • Have an SVN post-commit-Hook that is blocking and syncing via svnsync. The problem here is obviously, that the commit is blocking until the data is transfered to the mirror.
  • Have an SVN post-commit-Hook that is non-blocking and syncing via svnsync. Here I see the following, more subtle problem: Imagine someone checks in a BIG file, and someone else shortly after that checks in a small file. Because the commit is non-blocking, two svnsync processes could be running at the same time and the small file could overtake the BIG file on the way to the mirror (this seems very time-critical and unlikely, although possible in principle). Their revision would swap.
  • Sync like every fifteen minutes with a cron-job. Same problem if a commit takes longer than 15 minutes and obviously that time-delay.

Did I forget a possibility? Did I get something wrong? Any ideas? Thank you already!

Maybe I should note that the second possibility is the one suggested by different web-sites. E.g. see http://www.kirkdesigns.co.uk/mirror-svn-repository-svnsync

share|improve this question
    
Because the commit is non-blocking, two svnsync processes could be running at the same time and the small file could overtake the BIG file on the way to the mirror (this seems very time-critical and unlikely, although possible in principle). Their revision would swap. This is not possible, svnsync replicates commits as they are written to the repository. They will always appear in revision order. –  Dave Cheney Mar 3 '10 at 9:23

1 Answer 1

up vote 3 down vote accepted

You could try an approach similar to the one we use at Atlassian

http://blogs.atlassian.com/developer/2008/11/subversion_replication_at_atla.html

disclaimer: I am currently an Atlassian employee, but was not involved in implementing this solution (only maintaining it)

As I said above in the comment, svnsync, run from a remote repository behaves deterministically. It cannot apply changesets out of order. So the only problem you have using a remote repository is the amount of lag due to changeset propagation.

share|improve this answer
    
+1 for the observation that svnsync cannot get out of order, the only problem is the potential latency. –  Jim T Mar 3 '10 at 9:55
    
You are totally right... I made a stupid thinking mistake. So the simple and beautiful SVN post-commit hook should do it in most cases. In case latency is a problem, one can take a look at the referenced Atlassian article. Thank you very much! –  roesslerj Mar 3 '10 at 13:19
    
Just be aware that the post commit hook will block the committer until the hook has run to completion. I'm not sure what happens if the post commit hook fails, I don't think the commit is rolled back, but it will be at least confusing. –  Dave Cheney Mar 3 '10 at 19:57
    
Well, using the post-commit hook, you can issue a command that immediately returns (e.g. via 'command &' on linux), having it non-blocking. Since the hook is post-commit it cannot rollback the commit. If svnsync fails, the next svnsync has to sync two revisions, which it simply does. The problem occurring here I would file under the topic latency. –  roesslerj Mar 8 '10 at 10:26

Your Answer

 
discard

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.