Version Control with Subversion - Login

Server ConfigurationCaveatsneed to do anything. Many teams don't use Subversion's locking features at all, so it maybe a nonissue for you. However, if lock changes aren't replicated from master to slaves, itmeans that clients won't be able to query the status of locks (e.g., svn status -u willshow no information about repository locks). If this bothers you, you can write post-lockand post-unlock hook scripts that run svn lock and svn unlock on each slave machine,presumably through a remote shell method such as SSH. That's left as an exercisefor the reader!Your master/slave replication system should now be ready to use. A couple of words ofwarning are in order, however. Remember that this replication isn't entirely robust in theface of computer or network crashes. For example, if one of the automated svnsync commandsfails to complete for some reason, the slaves will begin to fall behind. For example,your remote users will see that they've committed revision 100, but then when they run svnupdate, their local server will tell them that revision 100 doesn't yet exist! Of course, theproblem will be automatically fixed the next time another commit happens and the subsequentsvnsync is successful—the sync will replicate all waiting revisions. But still, youmay want to set up some sort of out-of-band monitoring to notice synchronization failuresand force svnsync to run when things go wrong.Can We Set Up Replication with svnserve?If you're using svnserve instead of Apache as your server, you can certainly configureyour repository's hook scripts to invoke svnsync as we've shown here, therebycausing automatic replication from master to slaves. Unfortunately, at the time of thiswriting there is no way to make slave svnserve servers automatically proxy write requestsback to the master server. This means your users would only be able to checkout read-only working copies from the slave servers. You'd have to configure yourslave servers to disallow write access completely. This might be useful for creatingread-only “mirrors” of popular open source projects, but it's not a transparent proxyingsystem.Other Apache featuresSeveral of the features already provided by Apache in its role as a robust web server canbe leveraged for increased functionality or security in Subversion as well. The Subversionclient is able to use SSL (the Secure Sockets Layer, discussed earlier). If your Subversionclient is built to support SSL, it can access your Apache server using https:// and enjoya high-quality encrypted network session.Equally useful are other features of the Apache and Subversion relationship, such as theability to specify a custom port (instead of the default HTTP port 80) or a virtual domainname by which the Subversion repository should be accessed, or the ability to access therepository through an HTTP proxy.Finally, because mod_dav_svn is speaking a subset of the WebDAV/DeltaV protocol, it'spossible to access the repository via third-party DAV clients. Most modern operating systems(Win32, OS X, and Linux) have the built-in ability to mount a DAV server as a standardnetwork “shared folder.” This is a complicated topic, but also wondrous when implemented.For details, read Appendix C, WebDAV and Autoversioning.Note that there are a number of other small tweaks one can make to mod_dav_svn thatare too obscure to mention in this chapter. For a complete list of all httpd.conf directivesthat mod_dav_svn responds to, see the section called “Directives”.Path-Based Authorization185