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