The first step is to set up a second Subversion server to be used as a mirror. We’ll call that source-server from now on. Step One: Set up Subversion on a 2nd Server This guide assumes you’re already running Subversion on one server.
Following are the steps and a few gotchas I learned this week as I finally had a chance to set up a proper Subversion mirror replication slave server. If you’re familiar with master-slave database replication, Subversion repository replication is quite similar. The best way to do this is to create a mirror repository on another server, and use the svnsync program to create a replica of your primary Subversion repository, or repositories, if you have multiple.
To extend the insurance metaphor, as great as it is having the code on your laptop backed up to a central Subversion server, it makes just as much sense to protect yourself from the possibility that your Subversion server’s hard drive will crash. Granted you can do the same thing with a master Git repository on or your own server in the cloud, but unlike Git, Subversion is meant to be run somewhere other than your laptop or workstation. Every time you commit, you’re sending that code to another server. One of the primary benefits of using Subversion as your SCM solution is that it’s like having an insurance policy against your local machine breaking, your laptop being stolen, or your hard drive crashing. That is, when you use Git to commit hundreds or even thousands of revisions to your local machine… what happens if your hard drive crashes? Unless you also have set up a remote repository and get familiar with pull requests and merges - Git actually requires a little more effort to get this big benefit - and it’s built into Subversion by design. Tons of developers love Git, and although Git does have some really great features when compared to Subversion, there’s one particular benefit to using Subversion that Git users rarely consider.