本文档旨在描述 Subversion 1.6.x 系列。如果您正在运行不同版本的 Subversion，我们强烈建议您访问 https://svnbook.subversion.org.cn/ 并查阅适合您 Subversion 版本的文档。
那么，您应该使用哪个服务器？哪个最好？
显然，这个问题没有正确答案。每个团队都有不同的需求，不同的服务器代表着不同的权衡。Subversion 项目本身并不支持任何特定服务器，也不认为任何服务器比其他服务器更 “官方”。
以下是一些您可能选择一种部署而不是另一种部署的原因，以及您可能 不 选择一种部署的原因。
快速简便地设置。
网络协议是有状态的，明显快于 WebDAV。
无需在服务器上创建系统帐户。
密码不会通过网络传输。
默认情况下，只有一种身份验证方法可用，网络协议未加密，服务器存储明文密码。（所有这些都可以通过配置 SASL 来更改，但这需要更多工作。）
没有高级日志记录功能。
没有内置的 Web 浏览。（您需要安装单独的 Web 服务器和存储库浏览软件来添加此功能。）
网络协议是有状态的，明显快于 WebDAV。
您可以利用现有的 SSH 帐户和用户基础设施。
所有网络流量都已加密。
只有一种身份验证方法可用。
没有高级日志记录功能。
它要求用户位于同一系统组，或使用共享 SSH 密钥。
如果使用不当，会导致文件权限问题。
它允许 Subversion 使用任何已经与 Apache 集成的众多身份验证系统。
无需在服务器上创建系统帐户。
提供完整的 Apache 日志记录。
网络流量可以通过 SSL 加密。
HTTP(S) 通常可以穿过公司防火墙。
通过 Web 浏览器提供内置的存储库浏览功能。
存储库可以作为网络驱动器挂载，以实现透明的版本控制（参见 名为“自动版本控制”的部分）。
明显慢于 svnserve，因为 HTTP 是一个无状态协议，需要更多的网络往返。
初始设置可能很复杂。
通常，本书的作者建议对小型团队使用标准的 svnserve 安装，这些团队只是尝试开始使用 Subversion 服务器；它是最简单的设置，并且维护问题最少。随着您需求的改变，您可以随时切换到更复杂的服务器部署。
以下是一些基于多年支持用户的经验得出的通用建议和技巧。
如果您尝试为您的团队设置最简单的服务器，标准的 svnserve 安装是最简单、最快的途径。但是请注意，您的存储库数据将在网络上明文传输。如果您的部署完全在公司的 LAN 或 VPN 内，则这不是问题。如果存储库暴露在公共互联网上，您可能需要确保存储库的内容不是敏感的（例如，它只包含开源代码），或者您需要多花一些功夫配置 SASL 来加密网络通信。
如果您需要与现有的传统身份系统（LDAP、Active Directory、NTLM、X.509 等）集成，您必须使用基于 Apache 的服务器或配置了 SASL 的 svnserve。
如果您决定使用 Apache 或标准的 svnserve，请在您的系统上创建一个单独的 svn 用户，并以该用户身份运行服务器进程。请确保存储库目录完全由 svn 用户拥有。从安全的角度来看，这可以很好地隔离和保护存储库数据，并且只有 Subversion 服务器进程本身可以更改这些数据。
如果您有一个以 SSH 帐户为基础的现有基础设施，并且您的用户已经在您的服务器机器上拥有系统帐户，那么部署 svnserve-over-SSH 解决方案是有意义的。否则，我们不建议公众广泛使用此选项。通常认为，让用户通过 svnserve 或 Apache 管理的（虚拟）帐户访问存储库，而不是通过完整的系统帐户，会更安全。如果您非常希望使用加密通信，我们建议您改为使用带有 SSL 的 Apache 或带有 SASL 加密的 svnserve。
不要被让所有用户直接通过 file:// URL 访问存储库的简单想法所吸引。即使存储库通过网络共享可以轻松地供所有人使用，这也不是一个好主意。它消除了用户和存储库之间的任何保护层：用户可能会意外地（或有意地）破坏存储库数据库，这使得很难将存储库脱机以进行检查或升级，并且会导致文件权限混乱（参见 名为“支持多种存储库访问方法”的部分）。请注意，这也是我们警告不要通过 svn+ssh:// URL 访问存储库的原因之一——从安全的角度来看，这与本地用户通过 file:// 访问的效果相同，如果管理员不小心，可能会导致相同的问题。