读者可能已经注意到 Subversion 非常灵活. 因为 Subversion 实现分支和 标签的底层机制是相同的 (目录复制), 而且分支和标签都是以普通的目录出现 在文件系统中, 很多人觉得自己被 Subversion 吓到了: 这简直就是 过于 灵活了. 本节将介绍一些与管理相关的建议.
有一些标准的方式用于组织仓库内容. 大多数用户用目录 trunk
存放开发 “主线”, 用目录 branches
存放分支, 用目录 tags 存放标签. 如果
一个仓库只存放一个项目, 人们通常会创建这些顶层目录:
/
trunk/
branches/
tags/
如果在一个仓库中包含了多个项目, 通常根据项目索引它们的布局, 关 于 “项目根目录” 的更多内容, 见 “规划仓库的组织方式”一节, 下面就是一个典型的, 包含了多个项目的仓库布局:
/
paint/
trunk/
branches/
tags/
calc/
trunk/
branches/
tags/
当然, 用户也可以完全忽略这些常见的布局, 按照实际需要定义仓库的 布局. 记住, 无论你怎么选择, 仓库布局并非一成不变, 用户可以在任何时候 重新组织仓库的布局. 因为分支和标签都是普通目录, 所以用户可以随心所欲地 用命令 svn move 移动或重命名它们. 从一种布局切换到 另一种布局只是服务器端的一系列移动而已, 如果你不喜欢当前的仓库布局, 可以任意修改目录结构.
记住, 虽然移动目录很容易操作, 但你仍然需要考虑其他用户. 把目录调 来调去可能会让其他用户感到迷惑, 如果有个用户的工作副本所对应的仓库目录 被其他用户用 svn move 移动其他地方去了, 那么用户下 次执行 svn update 时, 就会被告知工作副本对对应的仓库 目录已经不存在了, 他必须用 svn switch 把工作副本切换 到仓库中的另一个位置.
Subversion 模型具有的另一个优良特性是分支和标签的寿命是有限的,
就像一个普通的被版本控制的条目. 比如说用户最终在自己的分支中完成了工
作, 当分支上所有的修改都被合并到 /calc/trunk 后,
就没必要再在仓库中保留自己的分支了.
$ svn delete http://svn.example.com/repos/calc/branches/my-calc-branch \
-m "Removing obsolete branch of calc project."
Committed revision 474.
![[提示]](images/tip.png)
|
提示 |
|---|---|
|
上一小节刚刚讲过, 如果工作副本所对应的仓库路径已经被删除了, 此时 再更新工作副本将会收到错误: $ svn up Updating '.': svn: E160005: Target path '/calc/branches/my-calc-branch' does not exist 对于这种情况, 你所需要做的就是把工作副本切换到仓库中仍然存在的 其他路径: $ svn sw ^/calc/trunk D src/whole.c U src/real.c A src/integer.c U . Updated to revision 474. |
现在你的分支就消失了, 当然并非永远地消失: 分支只是在 HEAD
上看不到了. 如果用 svn checkout,
svn switch 或 svn list 查看较
早的版本号, 仍然可以看到你的旧分支.
如果浏览已删除的目录还不够, 你还可能把它们再恢复回来. 在 Subversion
中恢复数据非常容易, 如果用户想把一个已删除的目录或文件恢复到
HEAD 中, 只需要用 svn copy 把它从旧
版中复制出来即可:
$ svn copy ^/calc/branches/my-calc-branch@473 \
^/calc/branches/my-calc-branch \
-m "Restore my-calc-branch."
Committed revision 475.
在我们的例子里, 分支的寿命相对较短: 创建分支的目的可能是为了
修正一个问题, 或实现一个新的特性. 当任务完成后, 分支也就走到了生命的
尽头. 在软件开发过程中, 长期同时存在两条 “主要的” 分支并
不少见, 比如说现在要发布 calc 的稳定版本, 而开发
人员知道要花几个月的时间才能把潜在的问题修复殆尽, 也不想向稳定版添加
新特性, 所以你决定创建一个 “稳定” 分支, 表示不想做过多的
修改:
$ svn copy ^/calc/trunk ^/calc/branches/stable-1.0 \
-m "Creating stable branch of calc project."
Committed revision 476.
现在开发人员可以自由地向 /calc/trunk 添加最
前沿的 (或实验性的) 新特性, 同时达成一个约定: 只有修复问题的修改才能
提交到 /calc/branches/stable-1.0. 也就是说, 当人
们在主干上工作的同时, 精选修复问题的修改提交到稳定分支上. 即使在稳定
分支发布后, 开发人员很可能也会维护很长一段时间—只要你还在为客户
支持这一发布版. 我们将会在下节介绍更多的相关内容.
