SVN分支维护专家在线

本节讲解一下如何进行SVN分支维护，前面几节我们讲了SVN的分支与合并，相信大家应该掌握了，下面就SVN分支维护问题和大家讨论一下，希望对你有所启发。
你一定注意到了Subversion极度的灵活性，因为它用相同的底层机制（目录拷贝）实现了分支和标签，因为分支和标签是作为普通的文件系统出现，会让人们感到害怕，因为它太灵活了，在这个小节里，我们会提供安排和管理数据的一些建议。

版本库布局

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

/trunk  


/branches  


/tags  


[/pre]如果一个版本库保存了多个项目，管理员会通过项目来布局（见“规划你的版本库结构”一节关于“项目根目录”）：  


/paint/trunk  


/paint/branches  


/paint/tags  


/calc/trunk  


/calc/branches  


/calc/tags  


[/pre] 

当然，你可以自由的忽略这些通常的布局方式，你可以创建任意的变化，只要是对你和你的项目有益，记住无论你选择什么，这不会是一种永久的承诺，你可以随时重新组织你的版本库。因为分支和标签都是普通的目录，svnmove命令可以任意的改名和移动它们，从一种布局到另一种大概只是一系列服务器端的移动，如果你不喜欢版本库的组织方式，你可以任意修改目录结构。记住，尽管移动目录非常容易，你必须体谅你的用户，你的修改会让你的用户感到迷惑，如果一个用户的拥有一个版本库目录的工作拷贝，你的svnmove命令也许会删除最新的版本的这个路径，当用户运行svnupdate，会被告知这个工作拷贝引用的路径已经不再存在，用户需要强制使用svnswitch转到新的位置。下面我们看一下SVN分支维护中数据的生命周期。

数据的生命周期

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

$svndeletehttp://svn.example.com/repos/calc/branches/my-calc-branch\  


-m"Removingobsoletebranchofcalcproject."  


Committedrevision375.  


[/pre] 

你的分支已经消失了，当然不是真的消失了：这个目录只是在HEAD修订版本里消失了，如果你使用svncheckout、svnswitch或者svnlist来检查一个旧的版本，你仍会见到这个旧的分支。
如果浏览你删除的目录还不足够，你可以把它找回来，恢复数据对Subversion来说很简单，如果你希望恢复一个已经删除的目录（或文件）到HEAD，仅需要使用svncopy-r来从旧的版本拷贝出来：

$svncopy-r374http://svn.example.com/repos/calc/branches/my-calc-branch\  


http://svn.example.com/repos/calc/branches/my-calc-branch  


Committedrevision376.[/pre]  

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