### 分支维护 你一定注意到了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 checkout**、**svn 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修正,甚至在稳定版本发布之后。你或许会在这个维护分支上工作很长时间―也就是说,你会一直继续为客户提供这个版本的支持。