一、常规SVN开发过程
大多数软件存在这样一个生命周期:编码、测试、发布,然后重复。这样有两个问题,第一,开发者需要在质量保证小组测试假定稳定版本时继续开发新特性,新工作在软件测试时不可以中断,第二,小组必须一直支持老的发布版本和软件;如果一个bug在最新的代码中发现,它一定也存在已发布的版本中,客户希望立刻得到错误修正而不必等到新版本发布。
这是版本控制可以做的帮助,典型的过程如下:
-
开发者提交所有的新特性到主干。 每日的修改提交到
/trunk
:新特性,bug修正和其他。 -
这个主干被拷贝到“发布”分支。 当小组认为软件已经做好发布的准备(如,版本1.0)然后
/trunk
会被拷贝到/branches/1.0
。 -
项目组继续并行工作,一个小组开始对分支进行严酷的测试,同时另一个小组在
/trunk
继续新的工作(如,准备2.0),如果一个bug在任何一个位置被发现,错误修正需要来回运送。然而这个过程有时候也会结束,例如分支已经为发布前的最终测试“停滞”了。 -
分支已经作了标签并且发布,当测试结束,
/branches/1.0
作为引用快照已经拷贝到/tags/1.0.0
,这个标签被打包发布给客户。 -
分支多次维护。当继续在
/trunk
上为版本2.0工作,bug修正继续从/trunk
运送到/branches/1.0
,如果积累了足够的bug修正,管理部门决定发布1.0.1版本:拷贝/branches/1.0
到/tags/1.0.1
,标签被打包发布。具体操作可参考
整个过程随着软件的成熟不断重复:当2.0完成,一个新的2.0分支被创建,测试、打标签和最终发布,经过许多年,版本库结束了许多版本发布,进入了“维护”模式,许多标签代表了最终的发布版本。