SVN解决版本冲突问题.pdf

SVN 解决版本冲突功能 1 代码的分支管理策略 关于代码管理的分支和发布策略，目前主要有两种：一种是主干作为新功能开发主线，分支用作发 布。另一种是分支用作新功能开发，主干作为稳定版的发布。 1.1 分支用来发布 典型操作步骤如下： 1) 开发者提交所有的新特性到主干。 每日的修改提交到/trunk ：新特性，bug 修正和其他。 2) 这个主干被拷贝到“待发布”分支。 当小组认为软件已经做好发布的准备（如，版本 1.0） 然后/trunk 会被拷贝到/branches/1.0 。 3) 项目组继续并行工作，一个小组开始对分支进行严酷的测试，同时另一个小组在/trunk 继续 新的工作（如，准备 2.0 ），如果一个 bug 在任何一个位置被发现，错误修正需要来回运送。 然而这个过程有时候也会结束，例如分支已经为发布前的最终测试“停滞”了。 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 分支被创建，测试、打标记和最 终发布，经过许多年，版本库结束了许多版本发布，进入了“维护”模式，许多标记代表了最终的发 布版本。 这种分支管理策略被广泛的应用于开源项目。比如 freebsd 的发布就是一个典型的例子。 freebsd 的主干永远是 current，也就是包括所有最新特性的不稳定版本。然后随着新特性的逐 步稳定，达到一个发布的里程碑以后，从主干分出来一个 stable 分支。freebsd 是每个大版本一个 分支。也就是说 4.x，5.x，6,x 各一个分支。每个发布分支上只有 bug 修改和现有功能的完善，而 不会再增加新特性。新特性会继续在主干上开发。当稳定分支上发生的修改积累到一定程度以后，就 会有一次发布。发布的时候会在稳定分支上再分出来一个 release 分支。以 6.x 为例，就会有 6.0,6.1,6.2…等发布分支。 这种发布方法非常适用于产品线的发布管理。产品是要卖的，以前卖给客户的版本仍需要继续维 护，而为了以后的市场，新功能也不断地在增加。这种管理方法对已发布产品的维护工作和下一代产 品的开发工作进行了隔离。对于已经发布的产品，只有维护的补丁发布。而新发行的产品不仅包括了 所有的 bug 修改，还包括了新功能。 这种方法具有如下缺点：首先，必须对主干上的新功能增加进行控制。只能增加下一个发布里面 计划集成进去的新特性。而且，已经在主干上集成的新特性中的任何一个，如果达不到里程碑的要求， 稳定分支就不能创建，这很有可能影响下一个发布的计划。开源项目可能这方面的压力小一些，但是 商业产品开发如果碰到这种情况就危险了。还有一个缺点就是 bug 修改必须在各个分支之间合并。 从分支和合并的一些实践经验上看，各个长期存在的分支之间必须要周期性的进行合并，否则很容易 引发合并冲突。可是各个 stable 分支以及 release 分支之间恰好是不能进行合并而且还要长期存在 的。因此，采用这种分支策略可能碰到的最大问题就是某个分支上的 bug 修改内容往其它分支 merge 的时候出现的冲突。而且一旦发现一个 bug，调查这个 bug 影响哪些分支的工作会随着维护的发布 分支的数量而增加。 -1- 在非产品开发的外包软件项目里面，这种发布方法的好处体现不出来，而缺点仍然存在。外包项 目的特点是客户永远需要“最新”的代码，因此对已经发布的某个分支进行维护的情况