情况：我们已经过beta，并且1.0版已发布到多个客户站点。 A团队已经在忙于1.1版的工作，该版本将进行逐步的错误修复和可用性调整，而另一个团队正在使用2.0版进行大规模更改，其中产品的核心可能已被完全重新设计。现在，对1.1所做的大多数更改都必须在某个时候进入2.0，并且实际上可能需要安排在2.0分支中进行的一些错误修复计划在更早的版本中进行。问题在于，由于2.0具有根本差异，因此如果不进行手动转换，则无法合并对1.1的更改，反之亦然。

我的问题：在这种情况下，最佳的修订控制措施是什么，以最大程度地减少合并冲突和重复工作？如何确保我的团队在版本控制问题上花费尽可能少的时间和精力，同时仍为客户提供常规补丁？

解决方案

回答

为此，我可能会依赖一个问题跟踪系统，并确保标记每个需要带入主干代码的更改。然后，我们可以确保每个更改的签入注释都引用了相关问题，并且清楚地表达了代码更改的意图，以便在尝试在中继中重新实现时可以轻松理解它。

回答

这里的文章(使用Subversion的日常工作)提到一种方法是使用1.1版构建中的数据不断更新2版。在文章中，那个家伙说每天都要这样做。

我们将要阅读的部分标题为"服务员，我的行李箱中有一个错误！"。大约是文章的一半。

回答

一种好的方法是修复稳定分支中的每个错误，然后将稳定分支合并到开发分支中。这是"并行维护/开发线"模式，关键是尽早并经常合并。不频繁合并和后期合并意味着与稳定分支相比，无法识别开发分支，或者无法以相同方式重复该错误。

从1.5版开始，Subversion包含合并跟踪，因此我们确保同一更改集不会被合并两次，从而导致愚蠢的冲突。存在其他系统(例如Git，Mercurial，Accurev，Perforce)，这些系统使我们可以进行以下类型的查询："分支A上的哪些更改尚未合并到分支B中？然后将需要的修补程序挑选到dev分支。

回答

尽早合并，经常合并，并确保主线上的质量保证了解并回归/验证在维护版本的每个补丁中修复的缺陷。

让某些问题溜走并在后续版本中"修复"错误真的很容易，并且让我告诉我们，客户不在乎管理多个分支会变得多么复杂-这就是工作。

确保我们使用的是支持分支和合并的源代码控制系统(我曾经有过Perforce和SVN的经验，虽然Perforce更好，但SVN是免费的)。

我还相信，由一个人以一致的方式负责执行合并有助于确保合并定期发生。通常是我或者我们团队中的资深人士之一。

回答

我们在工作中处理此问题的方法是将主干分支保持为最前沿的代码(在本例中为2.0)。我们为1.x代码创建一个分支，并在那里进行所有修复。对1.x所做的任何更改都应合并(如果需要，可以手动)到主干(2.0)分支中。

然后，我会坚持要求1.x开发人员在该错误的票证中同时记录1.x提交的修订版本号和2.0合并的修订版本号。这样，如果有人忘记合并他们的更改，就会更容易发现，而且他们必须保持追踪的事实他们记住。

回答

几乎所有其他人都说过，但是我认为我会抛弃使用SVN处理多个分支中的开发的经验

对于我们的主要产品，我们需要同时同时开发2个以上的版本。

我最初将主干用作"主开发"版本，并为每个实际发行版使用了标签。分支用于新功能集的大量开发工作。然后，当我们一次开始处理2、3和4个发行版时，我开始为每个修订版本使用一个分支。

由于我维护资源库并负责推动质量检查构建，因此请确保每天早晨进行"汇总"，其中包括将更改从当前活动最低的分支开始合并到树上。因此，我最终合并了从1.1到1.2的更改，该更改与自上次合并以来来自1.2的任何其他更改合并到1.3中，等等。

当我提交时，请确保始终用类似以下内容的注释来评论该提交：

merged 1.1 rev 5656-5690

可能会有点痛苦，但是它是可行的:)

回答

此图是Build Doctor捕获的一个关键点：仅合并一个方向。

回答

为了回答这个特定问题，许多开发人员已从Subversion切换到Git。检出github.com。