Purpose: A master/slave server replication model for Subversion WebDAV-based transactions. Some or all clients interact with a slave server, but the slave transparently passes all of the write-oriented activites to the master (rewriting the content as necessary). The slaves are essentially read-only, but they do have a complete copy of the repository locally. This serves to alleviate read traffic from the master server, and may dramatically speed up read operations, if a slave is sited closer to the users. This model has several advantages to using a straight HTTP DAV-aware caching proxy, in that each slave can respond to all read-only requests without ever having to relay them to the master backend. Proxy server requirements: Subversion 1.5 or newer Apache HTTP Server 2.2.0 or higher with at least mod_proxy, mod_proxy_http, mod_dav, and mod_dav_svn enabled (Several fixes to mod_proxy were committed for this patch that were not backported to the 2.0 branch of httpd.) Example configuration: Participants: Slave -> slave.example.com (there can be many!) Master -> master.example.com (there can only be one!) A WebDAV client (ra_neon, ra_serf, other WebDAV clients) Each client does: % svn co http://slave.example.com/repos/slave/ ... % svn ci % ...etc... (The client can perform all operations as normal.) Each slave has: DAV svn SVNPath /my/local/copy/of/repos SVNMasterURI http://master.example.com/repos/master The master: The master MUST have a post-commit hook that updates all of the slaves. An example that does this using 'svnadmin dump'/'svnadmin load' and ssh is provided below. svnsync can be used instead, but is left as an exercise to the reader. Note that if revprop changes are permitted via a pre-revprop-change hook (which is not true by default), a post-revprop-change hook is needed as well, to propagate those changes to slaves. Additionally, if locks are permitted on the master repository, lock databases need to kept in sync via post-lock and post-unlock hooks on the master pushing the lock state to the slaves. (Username preservation is left as an exercise to the reader.) If the lock database is not propagated, users will not be able to accurately determine whether a lock is held - but locking will still work. ---- #!/bin/sh REPOS="$1" REV="$2" SLAVE_HOST=slave.example.com SLAVE_PATH=/my/local/copy/of/repos # Ensure svnadmin is in your PATH on both this machine and the remote server! svnadmin dump --incremental -q -r"$REV" "$REPOS" | ssh $SLAVE_HOST "svnadmin load -q $SLAVE_PATH" ---- Issues/Thoughts: - The master maybe should update the slaves using a DAV commit of its own. (essentially replay the commit once it is approved). This requires a way to inject commits/user to the slave. But, this would eliminate the reliance on post-commit hooks. - This isn't multi-master replication. The slave won't accept commits on its own. If the master can't be contacted for a write operation, it will return a proxy error. (Multi-master == distributed repositories.) - Remove the location_filter for the header. I believe mod_proxy does this for us already. We may just be duplicating things. We will still have to rewrite the bodies of the requests/responses though. Apache-2.2.11's mod_proxy does no such Location Header fixing may be the Later versions could. - Determine a better way to handle the MERGE call. It's the only operation that doesn't occur on the activity URL.