对合并Mercurial中的旧分支有一些帮助 [英] Some help with merging legacy branch in Mercurial

问题描述

我们目前正在开发应用程序的新版本(2.0版).

We're currently working on the new version (version 2.0) of an application.

我们有一位运行该应用程序1.0版的客户发现了一个错误.我们更新了1.0版的标记变更集，并找到并修复了该错误.

We have a customer running version 1.0 of the app who found a bug. We updated to the tagged changeset for version 1.0 and located and fixed the bug.

我们进行了更改，从而在源代码树中创建了一个新头.

We committed the change which created a new head in our source tree.

问题是如何最好地将其合并?理想情况下，我希望将其合并到1.0版之后的变更集中.我不想将其合并到技巧中，因为发现错误的代码实际上不再存在.

The question is how best to merge this? Ideally I would want to merge it into the changeset that followed version 1.0. I don't want to merge it into the tip because the code where the bug was found doesn't actually exist anymore.

我意识到我也许应该为"v1.0错误修复"创建一个单独的分支.

I realise I perhaps should have created a separate branch for "v1.0 bug fix".

谢谢， 本

推荐答案

在使用合并在存储库中移动更改时，所有更改都与您拥有更改的位置和所需的位置的最新共同祖先有关.如果在进行此修复之前，您的存储库看起来像这样:

When moving a change within a repository using merge it's all about the most recent common ancestor of the place you have the change and the place you want it. If before making this fix your repo looked like this:

[a]-[b]-[c]-[d]

，其中带有1.0标记的更改集为[b]，那么您现在有了:

with the 1.0 tagged changeset being [b] then you now have this:

[a]-[b]-[c]-[d]
      \
       -[e]

修复程序在[e]中的位置. 如果是这种情况，那么您只需要这样做:

where the fix is in [e]. If that's the case then you just need to do this:

hg update d
hg merge e
hg commit

那么您将拥有:

[a]-[b]-[c]-[d]-[f]
      \         /
       -[e]-----

另一方面，在进行更改之前，您的存储库如下所示:

If on the other hand before making the changes your repo looked like this:

[a]-[b]-[c]-[d]
      \
       -[e]-[f]

其中的1.0抹布指向[f]，那么您现在有了:

where the 1.0 rag pointed to [f] then you now have this:

[a]-[b]-[c]-[d]
      \
       -[e]-[f]-[g]

，其中包含[g]中的修复程序.如果要将变更集[g]移到[d]而不带[e]和[f]，则没有很好的方法.提供给您的不太好方法(称为 cherrypicking )是使用hg export和hg import命令.

with the fix in [g]. If you want to move the changeset [g] into [d] without bringing [e] and [f] along with it, there's no good way to do it. The not-so-good way available to you (called cherrypicking) is to use the hg export and hg import commands.

没有工作流程需要精挑细选，但是避免工作流程需要一些周到的考虑.在第二种情况下，您可以通过不对1.0系列进行修订(作为[f]的子级)，而是作为希望更改的两个地方的最新共同祖先的子级来避免此问题.由于您希望同时在[d]和[f]中进行更改，因此您查找了它们的最新共同祖先，并看到它是[b]，然后使用以下命令将该更改作为子更改:

No workflow requires cherry picking, but avoiding it requires a little forethought. In that second case you would avoid it by making the fix not on the 1.0 series (as a child of [f]) but instead as a child of the most recent common ancestor of the two places you want that change. Since you want that change in both [d] and [f] you look for their most recent common ancestor and see it's [b] and make the change as a child of that using these commands:

hg update b
..edit..
hg commit

留下这张图:

[a]-[b]-[c]-[d]
      \
       \--[g]
        \
         -[e]-[f]

此修复程序，[g]是一个新的头，您可以将其合并到[d](2.0)和[f](1.0)中，而无需进行任何挑选.的命令将是:

this fix, [g] is a new head, and you can merge it into both [d] (2.0) and [f] (1.0) without any cherry picking at all. The commands for that would be:

hg update d
hg merge g
hg commit
hg update f
hg merge g
hg commit

，结果图将是:

[a]-[b]-[c]-[d]--[h]
      \         /
       \--[g]----
        \        \
         -[e]-[f]-[i]

其中[h]是具有修复程序的新2.0，而[i]是具有修复程序的新1.0.

where [h] is your new 2.0 with the fix, and [i] is your new 1.0 with the fix.

总结:您总是可以避免有预见的采摘樱桃，但是如果您不这样做，这并不是世界末日

Summary: you can always avoid cherry picking with forethought, but it's not the end of the world if you didn't

这篇关于对合并Mercurial中的旧分支有一些帮助的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！