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 不会偏爱任何一种, 也不会认为某种服务器配置更加 “官方”.
下面列出几点在选择服务器部署配置时应该考虑的因素.
设置方便.
网络协议是有状态的, 并且比 WebDAV 快很多.
不需要在服务器上创建系统帐户.
密码不会在网络上传输.
默认情况下, 只有一种认证方式可用, 网络协议是未加密的, 而且服务器以明文的形式存放密码. (这些都能通过配置 SASL 加 以修改, 但也带来了更多的工作量.)
缺乏高级的日志设施.
缺乏内建的网页浏览界面. (为了实现网页浏览, 管理员必须 安装额外的网页服务器和仓库浏览软件.)
网络协议是有状态的, 并且比 WebDAV 快很多.
管理员可以利用已有的 SSH 帐户和用户基础设施.
所有的网络流量都是加密的.
只有一种认证方式可用.
缺乏高级的日志设施.
要求用户属于相同的系统用户组, 或者使用共享的 SSH 密钥.
如果使用得不恰当, 将产生与文件权限有关的问题.
允许 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:// 的
情况是等效的, 如果管理员不够认真, 将会导致同样的问题.
You are reading Version Control with Subversion (for Subversion 1.8), by Ben Collins-Sussman, Brian W. Fitzpatrick, and C. Michael Pilato.
This work is licensed under the Creative Commons Attribution License v2.0.
To submit comments, corrections, or other contributions to the text, please visit http://www.svnbook.com/.