11.07.2015 Views

Version Control with Subversion - Login

Version Control with Subversion - Login

Version Control with Subversion - Login

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

Server ConfigurationThis configuration creates a huge perceptual speed increase for your users, because <strong>Subversion</strong>client traffic is typically 80–90% read requests. And if those requests are comingfrom a local server, it's a huge win.In this section, we'll walk you through a standard setup of this single-master/multiple-slavesystem. However, keep in mind that your servers must be running at least Apache 2.2.0(<strong>with</strong> mod_proxy loaded) and <strong>Subversion</strong> 1.5 (mod_dav_svn).Configure the serversFirst, configure your master server's httpd.conf file in the usual way. Make the repositoryavailable at a certain URI location, and configure authentication and authorizationhowever you'd like. After that's done, configure each of your “slave” servers in the exactsame way, but add the special SVNMasterURI directive to the block:DAV svnSVNPath /var/svn/reposSVNMasterURI http://master.example.com/svn…This new directive tells a slave server to redirect all write requests to the master. (This isdone automatically via Apache's mod_proxy module.) Ordinary read requests, however,are still serviced by the slaves. Be sure that your master and slave servers all have matchingauthentication and authorization configurations; if they fall out of sync, it can lead to bigheadaches.Next, we need to deal <strong>with</strong> the problem of infinite recursion. With the current configuration,imagine what will happen when a <strong>Subversion</strong> client performs a commit to the master server.After the commit completes, the server uses svnsync to replicate the new revision toeach slave. But because svnsync appears to be just another <strong>Subversion</strong> client performinga commit, the slave will immediately attempt to proxy the incoming write request back tothe master! Hilarity ensues.The solution to this problem is to have the master push revisions to a different on the slaves. This location is configured to not proxy write requests at all,but to accept normal commits from (and only from) the master's IP address:DAV svnSVNPath /var/svn/reposOrder deny,allowDeny from all# Only let the server's IP address access this Location:Allow from 10.20.30.40…Set up replicationNow that you've configured your Location blocks on master and slaves, you need to configurethe master to replicate to the slaves. This is done the usual way— using svnsync. Ifyou're not familiar <strong>with</strong> this tool, see the section called “Repository Replication” for details.First, make sure that each slave repository has a pre-revprop-change hook scriptwhich allows remote revision property changes. (This is standard procedure for being onthe receiving end of svnsync.) Then log into the master server and configure each of theslave repository URIs to receive data from the master repository on the local disk:183

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!