Subversion was designed with an abstract network 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 plugins that speak relevant network protocols. In theory, 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 webserver; 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 web 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. It only understands CRAM-MD5 authentication, has no logging, no web-browsing, and no option to encrypt network traffic. It is, however, extremely easy to 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 this scenario 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 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.
Here's a quick summary of the three typical server deployments.
表 6.1. Subversion サーバオプションの比較
機能 | Apache + mod_dav_svn | svnserve | svnserve over SSH |
---|---|---|---|
認証オプション | HTTP(S) basic 認証, X.509 認証, LDAP, NTLM, その他 Apache httpd で利用可能な方法 | CRAM-MD5 | SSH |
ユーザアカウントオプション | プライベート 'users' ファイル | プライベート 'users' ファイル | システムアカウント |
認可オプション | read/write access can be granted over whole repository, or specified per-path. | read/write access can be granted over whole repository, or specified per-path. | read/write access only grantable over whole repository |
暗号化 | オプションのSSL経由 | なし | SSH トンネル |
ログ | full Apache logs of each HTTP request, with optional 「high-level」 logging of general client operations | ログなし | ログなし |
相互運用性 | 部分的に他の WebDAVクライアントからも利用可能 | svn クライアントとのみ | svn クライアントとのみ |
ウェブによる参照 | 制限された組み込みサポート機能、あるいは ViewCVS のような サードパーティーのツール経由 | ViewCVS のようなサードパーティーツール経由のみ | ViewCVS のようなサードパーティーツール経由のみ |
スピード | やや遅い | やや速い | やや速い |
初期設定 | やや複雑 | 非常に簡単 | どちらかといえば簡単 |