情况：我们的测试版已结束，1.0 版已发布到多个客户站点。团队 A 已经忙于开发 1.1 版，该版本将进行增量错误修复和可用性调整，而另一个团队则致力于 2.0 版进行大规模更改，其中产品的核心可能已经完全重新设计。现在，为 1.1 所做的大部分更改都必须在某个时候进入 2.0，而在 2.0 分支中进行的一些错误修复实际上可能需要安排在较早的版本中。问题是，由于 2.0 有根本的不同，没有手动转换就不能合并 1.1 的变化，反之亦然。
我的问题：在这种情况下，将合并冲突和重复工作降至最低的最佳修订控制做法是什么？如何确保我的团队在修订控制问题上花费尽可能少的时间和精力，同时仍向客户提供定期补丁？
【问题讨论】：
标签： svn build-process release revision
为此，我可能会依赖问题跟踪系统，并确保标记需要提交到主干代码中的每个更改。然后，您可以确保每个更改的签入 cmets 都引用相关问题，并清楚地表达代码更改的意图，以便在尝试在主干中重新实现时易于理解。
【讨论】：
文章here (Day-to-day with Subversion) 提到一种方法是使用 1.1 版本构建的数据不断更新版本 2。在文章中，这家伙说每天都要这样做。
您要阅读的部分标题为“服务员，我的行李箱里有虫子！”。这篇文章已经写到一半了。
【讨论】：
一个好的方法是修复稳定分支中的每个错误并将稳定分支合并到开发分支中。这就是Parallel Maintenance/Development Lines 模式，关键是尽早并经常合并。不频繁合并和延迟合并意味着开发分支与稳定分支相比无法识别，或者错误不能以相同的方式重复。
Subversion 从 1.5 版开始包含合并跟踪，因此您可以确保相同的更改集不会合并两次，从而导致愚蠢的冲突。存在其他系统（例如，Git、Mercurial、Accurev、Perforce）可以让您查询“分支 A 上的哪些更改尚未合并到分支 B？”类型的查询。并挑选您需要的修复程序到 dev 分支。
【讨论】：
尽早合并，经常合并，并确保主线上的 QA 知道并回归/验证维护版本的每个补丁中修复的缺陷。
在后续版本中漏掉一些东西并“修复”一个错误真的很容易，让我告诉你，客户并不关心管理多个分支会变得多么复杂——这就是你的工作。
确保您使用的源代码控制系统支持分支和合并（我曾使用过 Perforce 和 SVN，虽然 Perforce 更好，但 SVN 是免费的）。
我还认为，让一个人负责以一致的方式执行合并有助于确保它们定期发生。通常是我或我们团队中的一位资深人士。
【讨论】：
我们在工作中处理这个问题的方式是将主干分支保持为最前沿的代码（即本例中的 2.0）。您为 1.x 代码创建一个分支，并在那里进行所有修复。对 1.x 的任何更改都应合并（如果需要，手动合并）到主干 (2.0) 分支。
然后我会坚持 1.x 开发人员在该错误的票证中记录 1.x 提交的修订号和 2.0 合并的修订号。这样一来，如果有人忘记合并他们的更改，就会更容易注意到，而且他们必须跟踪它的事实将有助于他们记住。
【讨论】：
几乎其他人都说过，但我想我会折腾我使用 SVN 在多个分支中处理开发的经验
对于我们的主打产品，我们需要同时开发2个以上的版本。
我最初使用主干作为“主要开发”版本，每个实际版本都使用标签。分支用于新功能集的大量开发工作。后来，当我们开始同时开发 2、3 和 4 个版本时，我开始为每个版本使用一个分支。
由于我维护存储库并处理推送 QA 构建，我确保每天早上都进行“汇总” - 这包括从当前最低的活动分支开始合并树上的更改。因此，我最终将 1.1 的更改合并到 1.2，该更改与 1.3 自上次合并以来的任何其他更改合并到 1.3，等等。
当我提交时，我确保总是用类似的东西评论提交
合并 1.1 rev 5656-5690
这可能有点痛苦，但它有效:)
【讨论】：
构建医生的this picture 中捕获了一个关键点：只合并一个方向。
【讨论】：
为了回答这个特定问题，许多开发人员已从 Subversion 切换到 Git。查看 github.com。
【讨论】：