本文档旨在描述 Apache™ Subversion® 的 1.7.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 安装是最简单、最快的途径。但是请注意，您的仓库数据将通过网络以明文形式传输。如果您的部署完全在公司的局域网或 VPN 内，这不是问题。如果仓库暴露在广阔的互联网上，您可能需要确保仓库内容不敏感（例如，它只包含开源代码），或者您需要额外配置 SASL 来加密网络通信。
如果您需要与现有的遗留身份系统（LDAP、Active Directory、NTLM、X.509 等）集成，您必须使用基于 Apache 的服务器或配置了 SASL 的 svnserve。
如果您决定使用 Apache 或标准的 svnserve，请在您的系统上创建一个名为 svn 的用户，并以该用户身份运行服务器进程。确保仓库目录完全由 svn 用户拥有。从安全角度来看，这将使仓库数据很好地隔离，并受到操作系统文件系统权限的保护，只有 Subversion 服务器进程本身可以更改这些权限。
如果您拥有一个高度依赖 SSH 帐户的现有基础设施，并且您的用户已经在您的服务器机器上拥有系统帐户，那么部署 svnserve 通过 SSH 的解决方案是有意义的。否则，我们不建议向公众广泛推荐此选项。通常，让您的用户通过 svnserve 或 Apache 管理的（虚拟）帐户访问存储库，而不是通过完整的系统帐户，被认为更安全。如果您仍然渴望使用加密通信，我们建议使用带有 SSL 的 Apache 或带有 SASL 加密的 svnserve。
不要被让所有用户通过 file:// URL 直接访问存储库的简单想法所诱惑。即使存储库通过网络共享对所有人可用，这也是一个坏主意。它消除了用户和存储库之间的任何保护层：用户可能会意外地（或故意地）损坏存储库数据库，使存储库脱机进行检查或升级变得困难，并且会导致文件权限问题（参见 名为“支持多种存储库访问方法”的部分）。请注意，这也是我们警告不要通过 svn+ssh:// URL 访问存储库的原因之一——从安全角度来看，它与本地用户通过 file:// 访问的效果相同，如果管理员不小心，可能会导致所有相同的问题。