在Mercurial使用移植的后果

在Mercurial中维护发布分支时,最近有几个关于跳过修改的问题。 例如:

  • Mercurial:分支具体变化在虚拟合并之后继续回来
  • 为什么一个分支的Mercurial退出会影响其他分支?

自2.0版本推出以来,我一直在想使用graft来避免这个问题。 给定一个像这样的修订树:

 A---B---C---D---E---F---G---H---I---J 

假设我们需要创build一个跳过邪恶变化E的释放分支。

 hg update -r D hg graft "F::J" 

给我们:

 A---B---C---D---E---F---G---H---I---J \ --F'--G'--H'--I'--J' 
  • Q1:这里发生了什么? 我可以理解, transplant将从F::J生成补丁,然后将它们应用到D ,但graft据说使用3路合并而不是补丁。 所以…….这是如何工作的? 为什么更好?

可以说,我现在修复E ,并将其合并到我的发布分支。

  --E2----------------- / \ A---B---C---D---E---F---G---H---I---J---M1 \ \ --F'--G'--H'--I'--J'---------M2-- 

M1是直接合并; 没有什么特别的。 M2正在合并具有“相同”(或至less等同)更改的分支。

  • Q2:这是合并使用DJ'M1的正常3路合并吗?
  • 问题3:mercurial存储/使用移植操作的额外信息来帮助合并?

最后…

  • 问题4:像这样的stream程有什么潜在的问题?

当你更新到D和移植F::J ,Mercurial运行一些合并。 它将从这个合并开始:

 M = three_way_merge(local=D, other=F, base=E) 

如果我们为状态CD之间的增量写+d ,那么我们从下面开始:

  +d +e +f ---- C ---- D ---- E ---- F ---- 

顺时针旋转graphics90度,上面的三路合并看起来像这样:

  -e .---- D / E \ '---- F +f 

也就是说,我们假设我们从E开始,然后用-e的相反方向到达D 我认为是+e的逆向补丁。 从E开始,我们也用正常的delta +f去了F状态。 这里没有什么奇怪的 – 我们已经在仓库中拥有所有的状态( DEF )。 所以如此看来,很显然我们可以合并DF

合并是一个“完成钻石”的事情。 因此,我们find一个新的状态M ,它是DF的混合, DM的差别与+f相似,从FM的差别与-e相似。 它看起来像这样:

  -e +f' .---- D ----. / \ EM \ / '---- F ----' +f -e' 

+f delta变成+f'-e delta变成-e' 。 这只是一个正常的三路合并,但效果很有趣:我们已经将F应用到D而不是E

合并之后, MF的第二个父项被删除:

  -e +f' .---- D ----. / \ EM \ '---- F +f 

重申一下:我们已经将F的“效应”复制到D ,也就是说,我们已经发现了应用于D的增量( +f' )给出的效果与将+f应用于E时的效果相同。 我们可以稍微拉直一下图表来得到:

  +f' --- D ---- M \ '---- E ---- F +e +f 

结果是F使用全部的三路机械接枝到D

  • Q1:这里发生了什么? 所以…….这是如何工作的? 为什么更好?

    A1:使用合并比补丁更好,因为合并机制将重命名考虑在内。

  • Q2:这是合并使用D,J'和M1的正常3路合并吗?

    A2:是的,嫁接不会改变graphics的拓扑结构。

  • 问题3: mercurial存储/使用移植操作的额外信息来帮助合并?

    A3:不。

  • 问题4:像这样的stream程有什么潜在的问题?

    A4:从合并的angular度来看,它应该可以工作。 它会复制一些可能让人困惑的历史。

Q1:有冲突时有帮助。 您可以使用通常的合并工具(对于我来说,它是内联冲突标记,我使用Emacs的合并模式进行编辑)。

Q2:这是一个正常的合并。

Q3:不。

Q4:我觉得有两个几乎完全相同的分支是很难看的。