Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

A Replication Architecture for Enterprise-Grade Subversion : Page 2

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.


advertisement
Synchronize Your Repository with Style Using Svnsync
A much more efficient way of backing up your Subversion repository is to use svnsync. This useful tool, which dates from Subversion 1.4, works by relaying revisions (as a series of commit operations) to a replicated server. Essentially, the replicated server “replays” each commit on its own copy of the repository. This approach is much more efficient than backing up the entire repository each time; only the data required for the commits performed since the last synchronization are transmitted. In addition, you can use svnsync over the network, using either of the standard Subversion protocols, svn:// or http://.

Setting up svnsync is easy enough. To start, all you need are two running Subversion repositories: one with the data you want to mirror, and the other empty. You can create an empty target repository on the mirror server as you would any other Subversion repository, using the 'svnadmin' command as shown here:

$ svnadmin create /var/svn/repos-mirror



It is important to check that the target repository does not already contain any revision data. For all intents and purposes, the target repository should be treated as a read-only repository that only synsync will use. Indeed, if you try to update this backup repository independently, Subversion likely will become very confused.

Before you can start backing up to this replicated server, you do need to make one minor configuration change to the mirror repository. During the synchronization process, svnsync needs to update revision properties on the mirrored server. Modifying revision properties is not activated by default in a new Subversion repository; you need to activate it by writing a pre-revprop-change hook script. This is easier to do than it sounds. In the hooks directory of your target Subversion repository, you will find a set of sample hook script templates, which you can examine to get an idea of how these scripts work.

At this stage, you need to allow revision properties to be updated. To do this, rename the file to pre-revprop-change.tmpl, pre-revprop-change on Unix, or pre-revprop-change.bat on Windows, and make it executable (if required). Then, modify the script so that it always returns 0 as follows:

#!/bin/sh exit 0

This authorizes all updates to revision properties without distinction.

Next, set up your main repository so that it synchronizes with your mirror repository. To do this, use the following command:

$ svnsync init svn://svnmirror svn://svnrepos

This prepares the svnrepos repository to be synchronized with the one on svnmirror. To actually perform the synchronization, you need to run svnsync sync as shown here:

$ svnsync sync svn://svnmirror Committed revision 1. Copied properties for revision 1. Committed revision 2. Copied properties for revision 2. Committed revision 3. Copied properties for revision 3. Committed revision 4. Copied properties for revision 4. Committed revision 5. Copied properties for revision 5. Committed revision 6. Copied properties for revision 6. Committed revision 7. Copied properties for revision 7. Committed revision 8. Copied properties for revision 8. Committed revision 9. Copied properties for revision 9. Committed revision 10. Copied properties for revision 10. ...

After this is done, your mirror repository contains a carbon copy of your main one.

Securing Your Replicated Server
As previously mentioned, your replicated server is a fragile beast. So you don't want just any old user committing changes to this repository. A good way to ensure this is to enforce strict user-access rights. To do this, create a special user with exclusive access to this repository. Call it something like syncuser (as the examples to follow do).

In this case, you need to make your pre-revprop-change script a bit more sophisticated. The following script will allow only syncuser to make updates to revision properties:

#!/bin/sh USER="$3" if [ "$USER" = "syncuser" ]; then exit 0; fi echo "Only the syncuser user may change revision properties" >&2 exit 1

You also need a similar script for the start-commit hook, to ensure that it can commit changes only to this repository.

Finally, when you initialize your replication process using this strategy, you need to provide the username and password for syncuser as follows:

$ svnsync init svn://svnmirror svn://svnrepos —sync-username syncuser –sync-password=secret



Comment and Contribute

 

 

 

 

 


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

 

 

Sitemap