This section is from the "Version Control with Subversion" book, by Ben Collins-Sussman, Brian W. Fitzpatrick and C. Michael Pilato. Also available from Amazon: Version Control with Subversion.
Now that you've configured your Location blocks on master and slaves, you need to configure the master to replicate to the slaves. This is done the usual way, using svnsync. If you're not familiar with this tool, see the section called “Repository Replication” for details.
First, make sure that each slave repository has a
pre-revprop-change
hook script which
allows remote revision property changes. (This is
standard procedure for being on the receiving end of
svnsync) Then log into the master
server and configure each of the slave repository URIs to
receive data from the master repository on local
disk:
$ svnsync init http://slave1.example.com/svn-proxy-sync file://var/svn/repos Copied properties for revision 0. $ svnsync init http://slave2.example.com/svn-proxy-sync file://var/svn/repos Copied properties for revision 0. $ svnsync init http://slave3.example.com/svn-proxy-sync file://var/svn/repos Copied properties for revision 0. # Perform the initial replication $ svnsync sync http://slave1.example.com/svn-proxy-sync Transmitting file data .... Committed revision 1. Copied properties for revision 1. Transmitting file data ....... Committed revision 2. Copied properties for revision 2. … $ svnsync sync http://slave2.example.com/svn-proxy-sync Transmitting file data .... Committed revision 1. Copied properties for revision 1. Transmitting file data ....... Committed revision 2. Copied properties for revision 2. … $ svnsync sync http://slave3.example.com/svn-proxy-sync Transmitting file data .... Committed revision 1. Copied properties for revision 1. Transmitting file data ....... Committed revision 2. Copied properties for revision 2. …
After this is done, we configure the master server's
post-commit
hook script to invoke
svnsync on each slave server:
#!/bin/sh # Post-commit script to replicate newly-committed revision to slaves svnsync sync http://slave1.example.com/svn-proxy-sync > /dev/null 2>&1 svnsync sync http://slave2.example.com/svn-proxy-sync > /dev/null 2>&1 svnsync sync http://slave3.example.com/svn-proxy-sync > /dev/null 2>&1
The extra bits on the end of each line aren't
necessary, but they're a sneaky way to allow the sync
commands to run in the background, so that the Subversion
client isn't left waiting forever for the commit to
finish. In addition to this
post-commit
hook, you'll need a
post-revprop-change
hook as well, so
that when a user, say, modifies a log message, the slave
servers get that change as well:
#!/bin/sh # Post-revprop-change script to replicate revprop-changes to slaves REV=${2} svnsync copy-revprops http://slave1.example.com/svn-proxy-sync ${REV} > /dev/null 2>&1 svnsync copy-revprops http://slave2.example.com/svn-proxy-sync ${REV} > /dev/null 2>&1 svnsync copy-revprops http://slave3.example.com/svn-proxy-sync ${REV} > /dev/null 2>&1
The only thing we've left out here is what to do about
locks. Because locks are strictly enforced by the master
server (the only place where commits happen), we don't
technically need to do anything. Many teams don't use
Subversion's locking features at all, so it may be a
non-issue for you. However, if lock changes aren't
replicated from master to slaves, it means that clients
won't be able to query the status of locks
(e.g. svn status -u will show no
information about repository locks.) If this bothers you,
you can write post-lock
and
post-unlock
hook scripts which run
svn lock and svn
unlock on each slave machine, presumably through
a remote shell method such as SSH. That's left as an
exercise for the reader!