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