假设您有两个"主线"分支，它们已经单独开发了很长时间，当您在它们之间进行合并时，您希望将所有开发人员的工作分开。
。你希望c#程序员合并c# cope，而TSQL程序员正在合并存储进程。
我清洗了所有开发人员，以便能够看到仍然需要合并的内容，并且结果彼此合并，Mercurial可以帮助实现这一点吗?
[我假设有不止一个开发人员在被告知他们将不得不进行合并后离开!)
正如我在评论中被问到的，这就是我认为我们是如何进入这种状态的…
如果我正确理解历史从我加入之前。一个大客户走过来说:"如果你在你的产品中添加x,y和z，我们将付给你很多钱，但我们不愿意冒你给我们任何不能直接受益的更改的风险(他们甚至把他们自己的一些程序员放在团队中，以检查他们没有得到其他更改)。"
在为这个大客户开展工作的几年中，其他客户说如果我们不添加a, b和c，他们就不会购买产品"。
大客户不愿意支付x、y和z的费用，因为这样做(或者可以关闭)不会破坏其他以不同方式使用它的客户的产品，而且大多数了解系统的程序员都是卖给大客户的，所以(直到现在)没有人力来修复x、y和z，这样它们就可以提供给我们所有的客户。
(基本上试图建立一个基于咨询收入的产品 -事实上，我们是由一家与大客户密切相关的公司带来的，这使得政治更加复杂。)
在所有这一切开始的时候，产品没有太多的自动化测试覆盖，代码基础回到。net v1发布时，所有的功能都很好地集成在UI和源代码中。
希望历史不会重演，但在一个没有很多软件公司的城市里，程序员很难说不。我们现在搬到水星，我想知道如果历史重演，我们如何应对水星!(我也开始质疑Mercurial是否真的能与Perforce相比)
是的，有一个针对该场景的工作流。
提前计划，在分支之前知道哪个分支会合并到哪个分支，并确保你定期合并到它。
示例:您有默认的分支，并且创建了一个特性分支，该分支在某些时候应该合并回默认分支。定期从默认状态合并到特性分支中，以确保默认状态下的所有更改都是最新的。这在过程中产生了较小的冲突。最后，你做最后一次合并到你的特性分支中，修复任何冲突，然后将其合并为默认。
这避免了最后的"大合并"，并产生了更容易管理的冲突。
一个明智的方法是使用hg convert将存储库分成更小的部分(c#部分，TSQL部分等)，对那些更小更细粒度的存储库执行合并，并且(如果保留原始的repo很重要)一旦准备好就将结果提交回原始存储库。
可能最接近您想要实现的是一次合并一个更改集。通过大量的小合并避免了大爆炸合并。如果你在c#开发人员和TSQL开发人员之间有明确的分离(这听起来像你做的)，那么你应该能够将每个更改集分配到正确的组。
这种方法最大的缺点是，您将无法通过并行地执行变更集来加速过程。
这种方法最大的好处是，您可以在每次合并(或一小组合并)之后进行测试，从而更容易跟踪破坏应用程序的更改。如果您目前没有一个强大的自动化测试套件，我强烈建议您首先加强它。