Version Control with Subversion - Login

Chapter 6. Server ConfigurationA Subversion repository can be accessed simultaneously by clients running on the samemachine on which the repository resides using the file:// method. But the typical Subversionsetup involves a single server machine being accessed from clients on computersall over the office—or, perhaps, all over the world.This chapter describes how to get your Subversion repository exposed outside its host machinefor use by remote clients. We will cover Subversion's currently available servermechanisms, discussing the configuration and use of each. After reading this chapter, youshould be able to decide which networking setup is right for your needs, as well as understandhow to enable such a setup on your host computer.OverviewSubversion was designed with an abstract network layer. This means that a repository canbe programmatically accessed by any sort of server process, and the client “repository access”API allows programmers to write plug-ins that speak relevant network protocols. Intheory, Subversion can use an infinite number of network implementations. In practice,there are only two servers at the time of this writing.Apache is an extremely popular web server; using the mod_dav_svn module, Apache canaccess a repository and make it available to clients via the WebDAV/DeltaV protocol,which is an extension of HTTP. Because Apache is an extremely extensible server, itprovides a number of features “for free,” such as encrypted SSL communication, logging,integration with a number of third-party authentication systems, and limited built-in webbrowsing of repositories.In the other corner is svnserve: a small, lightweight server program that speaks a customprotocol with clients. Because its protocol is explicitly designed for Subversion and is stateful(unlike HTTP), it provides significantly faster network operations—but at the cost ofsome features as well. While it can use SASL to provide a variety of authentication and encryptionoptions, it has no logging or built-in web browsing. It is, however, extremely easyto set up and is often the best option for small teams just starting out with Subversion.A third option is to use svnserve tunneled over an SSH connection. Even though thisscenario still uses svnserve, it differs quite a bit in features from a traditional svnserve deployment.SSH is used to encrypt all communication. SSH is also used exclusively to authenticate,so real system accounts are required on the server host (unlike vanilla svnserve,which has its own private user accounts). Finally, because this setup requires thateach user spawn a private, temporary svnserve process, it's equivalent (from a permissionspoint of view) to allowing a group of local users to all access the repository viafile:// URLs. Path-based access control has no meaning, since each user is accessingthe repository database files directly.Table 6.1, “Comparison of subversion server options” provides a quick summary of thethree typical server deployments.Table 6.1. Comparison of subversion server optionsFeature Apache +mod_dav_svnop-AuthenticationtionsHTTP(S) basic auth,X.509 certificates,LDAP, NTLM, or anyother mechanismavailable to Apachehttpd156svnserveCRAM-MD5 by default;SSHLDAP, NTLM,or any other mechanismavailable toSASLsvnserve over SSH