分支维护

你一定注意到了Subversion极度的灵活性,因为它用相同的底层机制(目录拷贝)实现了分支和标签,因为分支和标签是作为普通的文件系统出现,会让人们感到害怕,因为它灵活了,在这个小节里,我们会提供安排和管理数据的一些建议。

版本库布局

有一些标准的,推荐的组织版本库的方式,许多人创建一个trunk目录来保存开发的“主线”,一个branches目录存放分支拷贝,一个目录保存标签拷贝,如果一个版本库只是存放一个项目,人们会在顶级目录创建这些目录:

/trunk
/branches
/tags

如果一个版本库保存了多个项目,管理员会通过项目来布局(见“选择一种版本库布局”一节关于“项目根目录”):

/paint/trunk
/paint/branches
/paint/tags
/calc/trunk
/calc/branches
/calc/tags

当然,你可以自由的忽略这些通常的布局方式,你可以创建任意的变化,只要是对你和你的项目有益,记住无论你选择什么,这不会是一种永久的承诺,你可以随时重新组织你的版本库。因为分支和标签都是普通的目录,svn move命令可以任意的改名和移动它们,从一种布局到另一种大概只是一系列服务器端的移动,如果你不喜欢版本库的组织方式,你可以任意修改目录结构。

记住,尽管移动目录非常容易,你必须体谅你的用户,你的修改会让你的用户感到迷惑,如果一个用户的拥有一个版本库目录的工作拷贝,你的svn move命令也许会删除最新的版本的这个路径,当用户运行svn update,会被告知这个工作拷贝引用的路径已经不再存在,用户需要强制使用svn switch转到新的位置。

数据的生命周期

另一个Subversion模型的可爱特性是分支和标签可以有有限的生命周期,就像其它的版本化的项目,举个例子,假定你最终完成了calc项目你的个人分支上的所有工作,在合并了你的所有修改到/calc/trunk后,没有必要继续保留你的私有分支目录:

$ svn delete http://svn.example.com/repos/calc/branches/my-calc-branch \
             -m "Removing obsolete branch of calc project."

Committed revision 375.

你的分支已经消失了,当然不是真的消失了:这个目录只是在HEAD修订版本里消失了,如果你使用svn checkoutsvn switch或者svn list来检查一个旧的版本,你仍会见到这个旧的分支。

如果浏览你删除的目录还不足够,你可以把它找回来,恢复数据对Subversion来说很简单,如果你希望恢复一个已经删除的目录(或文件)到HEAD,仅需要使用svn copy -r来从旧的版本拷贝出来:

$ svn copy -r 374 http://svn.example.com/repos/calc/branches/my-calc-branch \
                  http://svn.example.com/repos/calc/branches/my-calc-branch

Committed revision 376.

在我们的例子里,你的个人分支只有一个相对短的生命周期:你会为修复一个Bug或实现一个小的特性来创建它,当任务完成,分支也该结束了。在软件开发过程中,有两个“主要的”分支一直存在很长的时间也是很常见的情况,举个例子,假定我们是发布一个稳定的calc项目的时候了,但我们仍会需要几个月的时间来修复Bug,你不希望添加新的特性,但你不希望告诉开发者停止开发,所以作为替代,你为软件创建了一个“分支”,这个分支更改不会很多:

$ svn copy http://svn.example.com/repos/calc/trunk \
         http://svn.example.com/repos/calc/branches/stable-1.0 \
         -m "Creating stable branch of calc project."

Committed revision 377.

而且开发者可以自由的继续添加新的(试验的)特性到/calc/trunk,你可以宣布这样一种政策,只有bug修正提交到/calc/branches/stable-1.0,这样的话,人们继续在主干上工作,某个人会选择在稳定分支上做出一些Bug修正,甚至在稳定版本发布之后。你或许会在这个维护分支上工作很长时间—也就是说,你会一直继续为客户提供这个版本的支持。