Mercurial：跨版本合并/大量挑选答案

【问题标题】：Mercurial: cross-version merges / massive cherry-pickingMercurial：跨版本合并/大量挑选
【发布时间】：2014-05-29 12:30:20
【问题描述】：

情况

我们有 2 个版本（1.0 和 2.0）的项目都在积极维护。它基本上是同一个项目（就变化而言），但基于不同的基础版本（base1.0 和 base2.0）。 1.0 中更改的所有内容也必须移植到 2.0。 base1.0 和 base2.0 也是如此。

在 mercurial 中，我们有 4 个分支：base1.0、1.0、base2.0 和 2.0。像这样的：

                         __2.0
             __base2.0__/
            /
__base1.0__/___1.0____________

现在，每次我们在基础版本中更改某些内容时，我们都会在 base1.0 中进行更改并将 hg 合并到 base2.0。这里没有问题。

现在当我们对 1.0 做同样的事情并想要将它们合并到 2.0 中时，我们还必须重新合并整个 base1.0 分支到 2.0，尽管已经从 base1.0 创建了 base2.0。

解决此问题的最有效方法是什么？我有几种方法：

合并：如上所述，这会导致大量开销和重新完成已经完成的工作
graft aka cherry-pick：选择我们在 1.0 上所做的每一个更改，并使用 hg Graft 将它们移植到 2.0。虽然它在某些情况下确实有效，但它会创建重复的变更集，因为它以 1:1 的比例移植它们。我想要的是 1 次提交，其中包含在 1.0 上进行的所有更新，并移植到 2.0。
diff export：我还尝试将原始 1.0 和最新 1.0 之间的差异导出，然后将其导入 2.0。但这是一个补丁，补丁是邪恶的。而且处理起来不是很方便。

有什么想法吗？对整个 SCM 概念相对较新，我只是想听听其他人在这种情况下做了什么。谢谢。

【问题讨论】：

您能否详细说明合并期间发生的情况？ Mercurial 不应该重做之前合并的事情。
我认为问题在于 2.0 与 1.0 没有直接关系，因此合并它会尝试将 base1.0 再次合并到 2.0 中，将 base1.0 作为唯一的共同祖先。在创建base2.0时已经解决的冲突必须再次解决。
你看过这种组织分支的方式吗？ andy.mehalick.com/2011/12/24/an-introduction-to-hgflow
我想我不明白为什么这会解决我的问题。我仍然必须有 2 个“主”分支，因为有两个不同的版本在相当长的时间内继续并排存在，不是吗？
是的，但我认为您的问题之一是您试图将整个 1.0 分支合并到 2.0。相反，您应该尝试为新功能创建单独的分支，将它们植根于您的历史中，在 1.0 和 2.0 之间的情况并没有太大差异的地方，然后将它们合并到 1.0 和 2.0 中。但很难说，因为我仍然不知道你遇到了什么样的合并问题，或者为什么 Mercurial 会这样。如果您已经处理过合并问题，那么在相同分支之间进行更多合并不应再次引发这些问题。

【解决方案1】：

我实际上解决了我的问题。我会添加它作为答案，也许其他人觉得它有用。

我真正需要的是挑选从 1.0 到 2.0 的所有更改。 hg Graft 做得很好，但在 2.0 上为每个移植的变更集创建了一个额外的提交，并弄乱了我的图表。

所以我所做的是创建我的 repo 的克隆，然后使用 hg 移植将所有变更集从 1.0 移植到 2.0。然后我导出了移植前和移植后的差异，并将该差异作为补丁导入到原始存储库中。

本质上是一种累积的“移植”，没有任何关于它来自何处的信息。在这种情况下，这正是我需要并为我工作的。

【讨论】：