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

By submitting your information, you agree that devx.com may send you DevX offers via email, phone and text message, as well as email offers about other products and services that DevX believes may be of interest to you. DevX will process your information in accordance with the Quinstreet Privacy Policy.


A Replication Architecture for Enterprise-Grade Subversion : Page 3

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.




Application Security Testing: An Integral Part of DevOps

Automating the Replication
After the synchronization is set up, it is easy to automate the whole process. Just add post-commit and post-revprop-change hooks to kick off a synchronization process in the background whenever any changes are committed. The post-commit script might look like this:

#!/bin/sh # Post-commit script to replicate newly committed revision to mirrors svnsync sync svn://svnmirror > /dev/null 2>&1

And the post-revprop-change hook could look like this:

#!/bin/sh # Post-revprop-change script to replicate revprop-changes to slaves REV=${2} svnsync copy-revprops svn://svnmirror ${REV} > /dev/null

Now, your mirrored repository will always synchronize with your main repository. And, if the network connection between the servers should fail, you're covered because the mirror will update the next time the connection is available.

Using Write-Through Proxying for Load Balancing
The discussion so far has concentrated on how to back up your Subversion repository to a remote mirror. This is a useful technique, but with Subversion 1.5 and Apache you can go much further. Subversion 1.5 introduces the idea of write-through proxying, which allows you to set up a distributed repository architecture that is well suited to geographically distributed teams.

Write-through proxying is based on the observation that the vast majority of operations on a Subversion repository are read-only. A write-through proxy architecture is composed of one central master repository and many read-only replicated repositories (see Figure 1). The replicated repositories are installed near local development teams. The replicated repositories are kept in sync with the central repository using an automated process based on svnsync.

Figure 1. Using Write-Through Proxying in Subversion: A write-through proxy architecture is composed of one central master repository and many read-only replicated repositories.

Whenever a developer performs a read-only operation, such as update, the request is processed directly by the local read-only replicated repository. Read/write operations (such as commits) are transparently sent to the central repository. When the update is done there, all of the distributed mirrors are also updated.

Write-through proxying works exclusively with Apache, and requires a bit of setting up. The rest of this section explains what's involved.

First of all, you need to set up your read-only replicated servers. The underlying replication mechanism of write-through proxying still relies on svnsync, so you need to prepare these servers using svnsync, as shown previously.

Next, you configure the replicated servers to run on Apache. The key part here is the Location element, which contains the new SVNMasterURI entry:

<Location /svn-mirror> DAV svn SVNPath /var/svn/svnmirror SVNMasterURI http://svnrepos </Location>

This tells Subversion to relay any update requests to the master server on http://svnrepos.

The mirror repository is in principle read-only. However, the master server needs to update it whenever it synchronizes the mirror repositories. To allow this, set up a special address on each slave server that only the master server can update:

<Location /svn-proxy-sync> DAV svn SVNPath /var/svn/svnmirror Order deny,allow Deny from all # Only let the server's IP address access this Location: Allow from </Location>

Finally, you need to set up post-commit and post-revprop-change hooks to synchronize the mirrored repositories after any updates. Note how the svnsync process is run in the background, so that it doesn't slow down the commits (this neat trick comes from the Subversion documentation):

#!/bin/sh # Post-commit script to replicate newly committed revision to mirrors svnsync sync http://slave1/svn-proxy-sync > /dev/null 2>&1 #!/bin/sh # Post-commit script to replicate newly committed revision to mirrors svnsync copy-revprops http://slave1/svn-proxy-sync > /dev/null 2>&1

After this is done, you should be good to go!

A Subversion-Based, Replicated Repository Architecture
Subversion replication is a powerful tool. Not only does it help you to backup your repositories reliably and efficiently, but it also can provide the foundation for a powerful and easy-to-configure replicated repository architecture. If you are setting up an enterprise-scale Subversion repository architecture, be sure to check it out!

John Ferguson Smart is principal consultant at Wakaleo Consulting, a company that provides consulting, training, and mentoring services in Enterprise Java and Agile Development. Well known in the Java community for his many published articles and talks, he is also the author of the book Java Power Tools.
Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



We have made updates to our Privacy Policy to reflect the implementation of the General Data Protection Regulation.
Thanks for your registration, follow us on our social networks to keep up-to-date