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 仓库在整体设计和技术上的简洁, 创建与配置仓库 是一项相对来说比较简单的任务. 需要做一些初步决定, 但是设置仓库所涉及 到的实际工作非常基础, 多做几次就能得心应手.
在开始创建仓库之前需要考虑的事情有:
仓库会存放哪些数据, 如何组织这些数据?
仓库会放在哪儿, 如何访问仓库?
你需要哪些类型的访问控制?
本节将帮助读者回答上面的几个问题.
虽然 Subversion 允许用户随意地移动目录和文件, 而不丢失任何信息, 甚至还可以把版本历史的整个集合从一个仓库移动到另一个仓库, 但这样做 难免会影响到那些需要经常访问仓库的人, 他们希望仓库及其文件的位置能 够保持稳定. 所以说在创建新的仓库之前, 试着为将来考虑, 提前做好规划. 提前认真地规划好仓库及其所管理的数据, 可以避免将来出现很多不必要的 麻烦.
假设仓库管理员需要为几个项目提供版本控制支持, 首先需要决定的 是用一个单独的仓库存放这些项目, 还是每个项目一个仓库, 还是介于两者 之间.
把多个项目放在一个单独的仓库里有一定的好处, 最明显的就是减少了 重复劳动. 一个单独的仓库意味着只有一个钩子集合, 需要例行备份的东西 只有一个, 如果 Subversion 发布了不兼容旧版的新版本, 只有一个仓库需 要转储和加载等. 另外, 用户还可以方便地在项目之间移动数据, 而不会丢失 任何历史信息.
缺点是不同的项目对仓库的事件触发的需求可能不同, 例如把提交通知发到不同 的邮件列表, 对于如何构成一次合法的提交, 其要求也会有所不同. 当然, 这些问 题并非无法克服—只是说所有的钩子脚本都依赖仓库的布局, 而不是假定整个 仓库只和单独的一组人有关系. 另外还要注意 Subversion 版本号的作用域是整个 仓库, 虽然这些数字并没有任何特殊的魔力, 但还是有人不喜欢看到这样一种情况: 虽然他们的项目最近都没有提交什么修改, 但是由于其他项目的活动, 他们自己的 项目的版本号仍然在不断增长.[48]
还有一种折衷一点的方式可以采用. 比如说根据项目之间的相关性进行 分组, 把相关性强的项目放在一个单独的仓库里. 这样的话项目之间共享数 据就会更加方便, 如果有新的版本号产生, 开发人员至少会知道这些新的版 本号和仓库中的项目都有或多或少的联系.
项目的组织方式确定后, 接下来就要考虑仓库内部的目录结构. 因为 Subversion
在创建分支和标签时使用的是常规的目录拷贝操作 (见 第 4 章 分支与合并), Subversion 社区建议管理员为每一个项目
的根目录—包含了所有与项目相关的数据的 “顶层” 目录
—选择一个仓库位置, 然后在项目根目录下创建 3 个子目录:
trunk
是开发主线; branches
存放所有的分支; tags
存放所有的标签.[49]
比如说, 仓库的目录结构可能是下面这样:
/
calc/
trunk/
tags/
branches/
calendar/
trunk/
tags/
branches/
spreadsheet/
trunk/
tags/
branches/
…
注意, 项目根目录在仓库中的位置并不重要. 如果每个仓库只包含一个项 目, 那么最常见的安排就是把仓库的根目录作为项目的根目录. 如果一个仓库 内包含了多个项目, 管理员可能会对它们进行分组, 例如把目标类似或共享代 码的项目放在同一个子目录内, 或者只是根据字母顺序进行分组. 一个例子是:
/
utils/
calc/
trunk/
tags/
branches/
calendar/
trunk/
tags/
branches/
…
office/
spreadsheet/
trunk/
tags/
branches/
…
管理员完全可以按照自己的喜好决定仓库的布局, Subversion 对仓库的布局 并没有特殊的要求—在它看来, 一个目录只是个目录而已. 总而言之, 仓库的布局应该满足项目及其开发人员的需求.
为了使讨论更加完整, 再介绍一种非常常见的仓库布局. 在这种布局里,
trunk
, tags
和
branches
位于仓库的根目录, 而各个项目是它们各
自的子目录, 例如:
/
trunk/
calc/
calendar/
spreadsheet/
…
tags/
calc/
calendar/
spreadsheet/
…
branches/
calc/
calendar/
spreadsheet/
…
这种布局并没有什么错误的地方, 但是对用户来说可能不够直观. 如果项 目很多, 并且每个项目都比较复杂, 开发人员也很多, 那么开发人员可能更希 望每个仓库只包含一两个项目. 但上面的做法倾向于弱化项目的独特性, 更 希望把整个项目集合看作一个单一的实体. 尽管这只是一个社会议题, 但我们 更希望读者使用一开始就推荐的仓库布局, 因为如果在一个单一的仓库路径上 单独记录了一个项目的整个历史, 那么查询 (修改或迁移) 单个项目的整个历 史—过去的, 现在的, 打过标签的和创建过分支的—就更加方便.
在创建你的 Subversion 仓库之前, 需要回答的一个问题是仓库应该放在 哪里. 这个问题关系到很多其他的选择, 例如仓库的访问方式 (是通过 Subversion 服务器进行访问, 还是直接访问), 哪些用户可以访问 (是只允许 公司的内部员工, 还是开放给整个互联网), 围绕着 Subversion 还提供了哪 些服务 (仓库浏览接口, 基于邮件的提交通知等), 数据的备份策略等.
本书在 第 6 章 服务器配置 介绍服务器的配置, 但我 们在这里要说明的是有些问题的答案可能会影响仓库的位置. 比如说特定的部 署场景可能会要求从多台计算机, 通过远程文件系统访问仓库, 或者是使用多 个仓库, 而这些仓库的数据是在地理上分布的同步数据, 从而为分散在世界各 地的用户提供更有效的访问. 介绍 Subversion 的每一种部署方式不仅不可能, 也超出了本书的范围, 我们只希望读者能根据本章的内容以及读者能找到的其他 参考资料, 评估自己的部署方式.
Subversion 的访问控制几乎全由 Subversion 服务器进程进行管理, 可 供选择的 Subversion 服务器在 第 6 章 服务器配置 介绍, 在 “基于路径的授权”一节 详细介绍基于路径 的访问控制. 除了用户级的访问控制外, 用户可能还希望仓库能被主机上的程序 访问. 操作系统层面的用户与用户组权限对仓库也有影响. 第 6 章 服务器配置 的内容将帮助读者解决与访问权限有关的 问题.