 |
Search |
 |
|
|
Replication in Subversion 1.5Posted by johnsmart on August 26, 2008 at 2:35 AM PDT
One common requirement when you set up a Subversion repository concerns how it will be backed up. Another involves what happens if the main repository server goes down for some reason. Yet another is about how to deal with teams distributed across large distances or connected with limited networks. Subversion has some interesting solutions to all of these concerns, notably via the svnsync tool, and more recently with a new feature called Write-Through Proxying, that makes setting up distributed repositories much easier. Earlier on this month I did a short talk at the Wellington JUG about using svnsync and Write-Through Proxying to set up distributed repositories with Subversion. The talk gives an overview of what's involved in setting up repository replication with svnsync, and shows how Write-Through proxying allows you to make life easier for remote developers. Although it doesn't go into too much detail (the Subversion documentation is pretty good), it does give a general idea of how it works. I've posted the slides for this presentation below. »
Comments
Comments are listed in date ascending order (oldest first)
Submitted by wandisco on Sat, 2008-08-30 09:02.
With Subversion 1.5, along with other notable new features such as built-in merge tracking, the WebDAV write-thru proxy will be introduced to simplify use of svnsync for Subversion deployments based around Apache 2.2.x.
Prior to Subversion 1.5, users had to manually redirect their client to the master server whenever they executed a commit or other write transaction using the “svn switch -- relocate†command. The WebDAV write-thru proxy will now detect when a commit or other write command has been issued by a client connected to a slave repository. It will then automatically redirect the client to the master server. This should make life somewhat easier for end users, and help prevent unintended writes against slave repositories from leading to split-brain scenarios that can be difficult to recover from.
However, the WebDAV write-thru proxy leaves svnsync's master-slave architecture unchanged. While svnsync does offer the advantage of local reads, eliminating WAN traffic that would otherwise take place between a remote client and a central Subversion server, writes only happen on the master. Thus, the master repository can become a single point of failure for write transactions. In addition, the lag time between each instance of master repository replication can result in users at remote sites checking out stale copies of source code files from their local slave. This in turn can lead to update conflicts when changes are committed against the master. If the replication process fails due to network outages or server crashes, there are no built-in recovery capabilities.
In contrast, WANdisco's Subversion MultiSite turns every Subversion repository into a peer of every other, and every repository is readable as well as writeable for the entire code base. Replication is triggered automatically when a write operation is done at any location, and transactional consistency is guaranteed across all of the repositories. Self-healing capabilities are provided to automate the recovery process after a network outage or server crash, and prevent any data loss.
Although both svnsync and Subversion MultiSite support the WebDAV HTTP protocol, Subversion MultiSite only uses this protocol over a LAN. WANdisco's own optimized protocol is used over a WAN on top of TCP/IP. The result is that commits consisting of hundreds of files are sent in a single pass during replication with Subversion MultiSite, rather than one-by-one as a series of HTTP PUTS, as is the case with svnsync. This enables Subversion MultiSite to deliver a significant performance boost over a wide area network.
With svnsync, user information, including access privileges must be maintained consistently across all of the servers, and there are no built-in features to support this. When WANdisco's Subversion Access Control solution is implemented with Subversion MultiSite, the security configuration is replicated automatically when it's initially set up, as are any changes, insuring consistency across all of the servers.
|
|
|
||
|
