如果您试图为您的团队设置最简单的服务器，使用普通的 svnserve 安装是最简单、最快的途径。但是请注意，您的存储库数据将通过网络以明文形式传输。如果您的部署完全在您公司的局域网或 VPN 内，这不成问题。如果存储库暴露于开放的互联网，您可能需要确保存储库的内容不敏感（例如，它只包含开源代码），或者您需要付出额外努力来配置 SASL 以加密网络通信。

如果您需要与现有的遗留身份系统（LDAP、Active Directory、NTLM、X.509 等）集成，您必须使用基于 Apache 的服务器或配置了 SASL 的 svnserve。

如果您已决定使用 Apache 或标准的 svnserve，请在您的系统上创建一个名为 svn 的用户，并将服务器进程作为该用户运行。确保存储库目录完全由 svn 用户拥有。从安全的角度来看，这将存储库数据很好地隔离并受操作系统文件系统权限保护，并且只有 Subversion 服务器进程本身才能更改这些权限。

如果您有一个现有的基础设施，它严重依赖于 SSH 帐户，并且您的用户已经在您的服务器机器上拥有系统帐户，那么部署通过 SSH 的 svnserve 解决方案是有意义的。否则，我们不建议公众广泛使用此选项。一般来说，让您的用户通过（虚拟）帐户访问存储库更安全，这些帐户由 svnserve 或 Apache 管理，而不是通过完整的系统帐户管理。如果您仍然渴望加密通信，我们建议使用带有 SSL 的 Apache 或带有 SASL 加密的 svnserve。

不要被让所有用户直接通过 file:// URL 访问存储库的简单想法所诱惑。即使存储库可以通过网络共享轻松供所有人使用，这也是一个坏主意。它消除了用户和存储库之间的任何保护层：用户可能会意外地（或故意地）损坏存储库数据库，使存储库脱机进行检查或升级变得很困难，并且会导致文件权限问题混乱（参见 名为“支持多种存储库访问方法”的部分）。请注意，这也是我们警告不要通过 svn+ssh:// URL 访问存储库的原因之一，从安全的角度来看，它与本地用户通过 file:// 访问的效果相同，如果管理员不小心，它会导致所有相同的问题。