10

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

roesslerj
  • 287
  • 1
  • 4
  • 11
  • _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 03 '10 at 09:23

2 Answers2

3

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

https://www.atlassian.com/blog/archives/subversion_replication_at_atla?_ga=2.217251286.1933127788.1517539727-1159165484.1517539727

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.

allen
  • 3
  • 1
Dave Cheney
  • 18,567
  • 8
  • 49
  • 56
  • +1 for the observation that svnsync cannot get out of order, the only problem is the potential latency. – Jim T Mar 03 '10 at 09: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 03 '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 03 '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 08 '10 at 10:26
0

Vanilla SVN lets you build a repository mirroring solution with the help of hook scripts and the svnsync tool (see SVNBook | Write-through proxying). Svnsync-based mirroring isn't entirely robust and has several limitations. E.g., svnsync does not support the lock-modify-unlock versioning model (it does not replicate file locks).

VisualSVN Server provides an alternative repository mirroring solution based on the VDFS (VisualSVN Distributed File System) technology. VDFS helps Subversion admins deploy writable mirrors of Subversion repositories without limitations of svnsync.

Disclaimer: I am a support engineer with VisualSVN Team.

bahrep
  • 687
  • 1
  • 9
  • 27