This text is a work in progress—highly subject to change—and may not accurately describe any released version of the Apache™ Subversion® software. Bookmarking or otherwise referring others to this page is probably not such a smart idea. Please visit http://www.svnbook.com/ for stable versions of this book.

选择一种服务器配置

那么, 我应该使用哪种服务器配置, 哪一种是最好的?

显然, 这个问题不存在正确的答案. 每一个开发团队都有不同的需求, 每一种服务器配置都代表了不同的权衡. Subversion 不会偏爱任何一种, 也不会认为某种服务器配置更加 官方.

下面列出几点在选择服务器部署配置时应该考虑的因素.

svnserve 服务器

应该用它的理由:
  • 设置方便.

  • 网络协议是有状态的, 并且比 WebDAV 快很多.

  • 不需要在服务器上创建系统帐户.

  • 密码不会在网络上传输.

不应该用它的理由:
  • 默认情况下, 只有一种认证方式可用, 网络协议是未加密的, 而且服务器以明文的形式存放密码. (这些都能通过配置 SASL 加 以修改, 但也带来了更多的工作量.)

  • 缺乏高级的日志设施.

  • 缺乏内建的网页浏览界面. (为了实现网页浏览, 管理员必须 安装额外的网页服务器和仓库浏览软件.)

svnserve + SSH

应该用它的理由:
  • 网络协议是有状态的, 并且比 WebDAV 快很多.

  • 管理员可以利用已有的 SSH 帐户和用户基础设施.

  • 所有的网络流量都是加密的.

不应该用它的理由:
  • 只有一种认证方式可用.

  • 缺乏高级的日志设施.

  • 要求用户属于相同的系统用户组, 或者使用共享的 SSH 密钥.

  • 如果使用得不恰当, 将产生与文件权限有关的问题.

Apache HTTP 服务器

应该用它的理由:
  • 允许 Subversion 去使用已经集成到 Apache 中的多种认证 机制.

  • 无需在服务器上创建系统帐户.

  • 有完备的 Apache 日志可供使用.

  • 网络流量经由 SSL 加密.

  • 一般来说, HTTP(S) 可以通过企业防火墙.

  • 内建的仓库浏览特性可被网页浏览器使用.

  • 仓库可以被当作网络驱动器进行挂载, 实现完全透明化的版本控制 (见 “自动版本控制”一节).

不应该用它的理由:
  • svnserve 慢得多, 因为 HTTP 是一 种无状态的协议, 需要更多的网络周转.

  • 初始设置比较复杂.

建议

一般情况下, 对于想要快速搭建 Subversion 服务器的小团队而言, 本书 作者推荐最普通的 svnserve, 它的设置最简单, 维护 成本也很低. 如果有新的需求产生, 管理员总是可以切换到更复杂的部署方式.

根据多年的用户支持经验, 下面列出几点一般性的建议和技巧:

  • 如果管理员想为团队搭建尽可能简单的 Subversion 服务器, 那么 最简单的选择就是 svnserve. 然而, 需要注意的是 仓库的数据将在网络上以明文形式传输, 如果服务器完全部署在公司的 LAN 或 VPN 内部, 那就不会带来什么问题. 相反, 如果仓库可被因特网 访问到, 管理员要么确保仓库存放的不是敏感数据 (例如只包含了开源 的代码), 要么使用 SASL 对网络传输进行加密.

  • 如果管理员想把已有的身份系统 (LDAP, Active Directory, NTLM, X.509 等) 集成到 Subversion 服务器中, 那就必须选择 Apache 服务器, 或配有 SASL 的 svnserve.

  • 如果管理员想使用 Apache 或 svnserve, 要在 服务器系统中创建一个新用户 svn, 然后以该用户的 身份运行服务器进程. 确保用户 svn 完全拥有仓库 目录, 从安全的角度来看, 这种做法使得仓库的数据能够保持孤立, 还能 利用操作系统的文件系统权限, 保证只有 Subversion 服务器进程才能修改 仓库目录.

  • 如果已有的基础设施严重依赖 SSH 账户, 并且团队成员在服务器上 都有自己的系统账户, 此时比较好的部署方式是 svnserve + SSH. 但如果是对外公开的仓库, 则我 们不建议这样做, 一般而言, 相比于真正的系统账户, 通过 svnserve 或 Apache 管理的 (虚假) 账户来访问 仓库是一种更安全的做法. 如果管理员对加密通信仍然具有强烈的渴望, 我们建议选择配有 SSL 的 Apache, 或配有 SASL 的 svnserve.

  • 不要 被这种简单的想法引诱: 让所有的用户 使用 file:// URL 直接访问仓库. 即使仓库已经 准备好通过网络共享被所有人访问, 但这仍然不是个好主意. 这种做法 移除了用户与仓库之间的所有保护层: 用户可以有意 (或无意) 地破坏 仓库数据库, 为了检查或升级而对仓库进行下线操作, 也会变得非常困难, 而且会产生一系列与文件权限有关的问题 (见 “支持多种仓库访问方法”一节). 注意, 这同时也是使用 svn+ssh:// URL 访问仓库时需要注意的地方— 从安全的角度来看, 它和本地用户使用 file:// 的 情况是等效的, 如果管理员不够认真, 将会导致同样的问题.