RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


A Replication Architecture for Enterprise-Grade Subversion

Sure, Subversion is the de facto leader in open source version control, but how does it stack up when it comes to enterprise-critical backup, replication, and load distribution? Pretty well, actually.

ubversion is by far the most popular open source version-control system, and for good reason. Its many powerful features, such as atomic commits, fast branching and tagging, efficient treatment of binary files, and HTTP and WebDAV access, make it an excellent choice for many organizations. Some of the more advanced features of Subversion 1.5—in particular merge tracking—make the system even more compelling.

A good version-control system is indeed strategically important for any software-development organization. As all developers know, your source code is the very lifeblood of an IT organization. So keeping your source code safe makes good business sense, and one of the main advantages of a source-code repository is knowing that your code is always safely tucked away in a safe place.

Or is it?

Servers can crash, networks can go down, and fires can destroy your data center—are you sure your source-code repository can be restored to a reasonable state quickly if you should face one of these emergencies? Are simple file system backups enough?

This article presents some strategies for making sure your Subversion repository is safely backed up, so that you can quickly restore it to its most recent state. It also demonstrates an easy way to set up a simple, yet powerful high-availability solution in the form of write-through proxying.

Backing Up Your Repository the Hard Way
A primary reason to back up your Subversion repository is to ensure that you can recover your precious source code in the event of a disaster. And one of the most basic backup strategies is simply to ensure that your data is regularly copied to a safe place. Subversion makes this easy.

By default, Subversion stores your repository in a flat file format known as FSFS. This format is portable and easy to duplicate and move around. By using the FSFS format for your repositories, you can restore any lost repository simply by copying the repository files back into the appropriate directory. However, if you simply copy your repository on a regular basis (say, every hour), you are likely to miss commits. Any changes that users commit to the repository between the last backup and a server crash is lost.

You can get around this problem by making sure that Subversion automatically backs up its data whenever a user commits. You can use the Subversion Hooks to do this. Hooks are a powerful scripting feature that every advanced Subversion user should know. The hooks directory of your Subversion repository should look something like this:

Kapiti:repos johnsmart$ ls hooks/
post-commit.tmpl          pre-lock.tmpl
post-lock.tmpl               pre-revprop-change.tmpl
post-revprop-change.tmpl     pre-unlock.tmpl
post-unlock.tmpl          start-commit.tmpl

These are essentially scripts that are executed at key points during the Subversion commit lifecycle. For example, the post-commit script will be executed just after each svn commit operation.

To get Subversion to back up your repository automatically, you could simply place a command in this script to back up your entire Subversion repository. This way, every time someone commits a change to your repository, the whole repository will be safely duplicated and placed out of harm's way.

The big problem with this approach, however, is that it is not particularly scalable. As your repository grows, so will the space needed to store all of the versions and the time required to back up the repository files. And restoring the repository after a crash is very much a manual task. Luckily, there's a better solution: a tool called svnsync.

Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date