SVN发布分支

大多数软件存在这样一个生命周期：编码、测试、发布，然后重复。这样有两个问题，第一 ，开发（Dev）小组需要在质量保证（QA）小组测试假定稳定版本时继续开发新特性，新工作在软件测试时不可以中断； 第二 ，项目组必须一直支持老的发布版本和软件，如果一个bug在最新的代码中发现，它一定也存在于已经发布的版本中，客户希望立刻得到错误修正而不等到新版本发布。

这是版本控制可以做的帮助，典型的过程 如下：

1. 开发提交所有的新特性到主干 。每日的修改提交到/trunk: 新特性， bug修正和其他。
2. 拷贝主干到“发布”分支 。当项目组认为软件已经做好发布的准备（如，版本1.0）然后/trunk会被拷贝到/branches/1.0.
3. 项目组继续并行工作 。QA小组开始对分支进行严格测试，同时Dev小组在/trunk继续新的工作（如，准备2.0）， 如果在任何一个位置(/trunk或/branches/1.0)发现bug, 那么错误的修正需要来回运送(/trunk运送到/branches/1.0或者/branches/1.0合并到/trunk)。然而这个过程有时候也 会结束，例如分支已经为发布前的最终测试“停滞”了。
4. 为分支做标签并且发布 。当测试结束，把/branches/1.0作为快照拷贝到/tags/1.0.0，把这个标签打包发布。
5. 分支多次维护 。继续在/trunk上为版本2.0工作，bug修正继续从/trunk运送到/branches/1.0，如果积累了足够的bug修正，当决定发布1.0.1版本时，拷贝/branches/1.0到/tags/1.0.1，标签被打包发布。

整个过程随着软件的成熟不断重复：当2.0完成，一个新的2.0分支被创建、测试、打标签和最终发布，经过长时间开发，版本库结束了许多版本的发布，进入了“维护”模式，许多标签代表了许多个发布版本。

Notes: 一个标签只是一个项目某一时间的“快照”，在Subversion里每一次提交的修订版本都是一个精确地快照。

参考自：SVN权威指南 第四章分支与合并 常用分支/合并模式--发布分支

http://www.subversion.org.cn/svnbook/