Subversion was designed with an abstract repository access layer. This means that a repository can be 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. In theory, Subversion can use an infinite number of network implementations. In practice, there are only two Subversion servers in widespread use today.
Apache HTTP Server (also known as httpd) is an extremely popular web server; using the mod_dav_svn module, Apache can access 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, it provides 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 web browsing of repositories.
In the other corner is svnserve: a small, lightweight server program that speaks a custom protocol 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 of some features as well. While it can use SASL to provide a variety of authentication and encryption options, it has no logging or built-in web browsing. It is, however, extremely easy to set up and is often the best option for small teams just starting out with Subversion.
The network protocol which svnserve
speaks may also be tunneled over an SSH connection. This
deployment option for svnserve 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 that each
user spawn a private, temporary svnserve
process, it's equivalent (from a permissions point of view) to
allowing a group of local users to all access the repository
via file:// URLs. Path-based access control
has no meaning, since each user is accessing the repository
database files directly.
Table 6.1, “Comparison of Subversion server options” provides a quick summary of the three typical server deployments.
Table 6.1. Comparison of Subversion server options
| Feature | Apache + mod_dav_svn | svnserve | svnserve over SSH |
|---|---|---|---|
| Authentication options | HTTP Basic or Digest auth, X.509 certificates, LDAP, NTLM, or any other mechanism available to Apache httpd | CRAM-MD5 by default; LDAP, NTLM, or any other mechanism available to SASL | SSH |
| User account options | Private “users” file, or other mechanisms available to Apache httpd (LDAP, SQL, etc.) | Private “users” file, or other mechanisms available to SASL (LDAP, SQL, etc.) | System accounts |
| Authorization options | Read/write access can be granted over the whole repository, or specified per path | Read/write access can be granted over the whole repository, or specified per path | Read/write access only grantable over the whole repository |
| Encryption | Available via optional SSL (https) | Available via optional SASL features | Inherent in SSH connection |
| Logging | High-level operational logging of Subversion operations plus detailed logging at the per-HTTP-request level | High-level operational logging only | High-level operational logging only |
| Interoperability | Accessible by other WebDAV clients | Talks only to svn clients | Talks only to svn clients |
| Web viewing | Limited built-in support, or via third-party tools such as ViewVC | Only via third-party tools such as ViewVC | Only via third-party tools such as ViewVC |
| Master-slave server replication | Transparent write-proxying available from slave to master | Can only create read-only slave servers | Can only create read-only slave servers |
| Speed | Somewhat slower | Somewhat faster | Somewhat faster |
| Initial setup | Somewhat complex | Extremely simple | Moderately simple |