情况:我们已经没有测试版,1.0版已经发布到几个客户站点.A团队已经忙于1.1版,它将进行增量错误修正和可用性调整,而另一个团队正在使用版本2.0进行大规模更改,其中产品的核心可能已经完全重新设计.现在,1.1的大部分更改都必须在某些时候进入2.0,并且2.0分支中的一些错误修复实际上可能需要安排在早期版本中.问题在于,由于2.0存在根本差异,因此无需手动转换即可合并1.1中的更改,反之亦然.
我的问题:在这种情况下,最小化合并冲突和重复工作的最佳修订控制实践是什么？如何确保我的团队在修订控制问题上花费尽可能少的时间和精力,同时仍然向客户提供定期补丁？
一个好方法是修复稳定分支中的每个错误并将稳定分支合并到开发分支中.这是并行维护/开发线模式,关键是尽早和经常合并.不频繁和晚期合并意味着开发分支与稳定分支相比是无法识别的,或者错误不能以相同的方式重复.
Subversion包括自版本1.5以来的合并跟踪,因此您可以确保相同的更改集未合并两次,从而导致愚蠢的冲突.存在其他系统(例如Git,Mercurial,Accurev,Perforce),可以让您查询类型"分支A上的哪些更改未合并到分支B中？" 和樱桃 - 挑选你需要的修补程序到开发分支.
京公网安备 11010802040832号 | 京ICP备19059560号-6 