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 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.
表 6.1 “Subversion 服务器选项比较”是三种典型服务器部署的总结。
表 6.1. Subversion 服务器选项比较
| 特性 | Apache + mod_dav_svn | svnserve | 穿越 SSH 隧道的 svnserve 服务器 |
|---|---|---|---|
| 认证选项 | HTTP Basic or Digest auth, X.509 certificates, LDAP, NTLM, or any other mechanism available to Apache httpd | 缺省是 CRAM-MD5；LDAP, NTLM 或任何 SASL 支持的机制。 | SSH |
| 用户帐号选项 | 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.) | 系统帐号 |
| 授权选项 | 可以授予整个版本库的读/写权限，也可以为每个路径指定 | 可以授予整个版本库的读/写权限，也可以为每个路径指定 | 只能对整个版本库授予读/写权限 |
| 加密 | Available via optional SSL (https) | 通过可选的 SASL 特性 | 继承 SSH 连接 |
| 日志 | 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 |
| 交互性 | 可以被其它 WebDAV 客户端访问 | 只同 svn 客户端通讯 | 只同 svn 客户端通讯 |
| Web 浏览能力 | 有限的内置支持，或者通过第三方工具，如 ViewVC | 只有通过第三方工具，如 ViewVC | 只有通过第三方工具，如 ViewVC |
| 主从服务器复制 | 从服务器透明代理写到主服务器 | 只能创建只读从服务器 | 只能创建只读从服务器 |
| 速度 | 有些慢 | 快一点 | 快一点 |
| 初始设置 | 有些复杂 | 极为简单 | 相对简单 |