在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：这是合并使用
D，J'和M1的正常3路合并吗？ - 问题3：mercurial存储/使用移植操作的额外信息来帮助合并？
最后…
- 问题4：像这样的stream程有什么潜在的问题？
当你更新到D和移植F::J ，Mercurial运行一些合并。 它将从这个合并开始：
M = three_way_merge(local=D, other=F, base=E)
如果我们为状态C和D之间的增量写+d ，那么我们从下面开始：
+d +e +f ---- C ---- D ---- E ---- F ----
顺时针旋转graphics90度，上面的三路合并看起来像这样：
-e .---- D / E \ '---- F +f
也就是说，我们假设我们从E开始，然后用-e的相反方向到达D 我认为是+e的逆向补丁。 从E开始，我们也用正常的delta +f去了F状态。 这里没有什么奇怪的 – 我们已经在仓库中拥有所有的状态（ D ， E和F ）。 所以如此看来，很显然我们可以合并D和F
合并是一个“完成钻石”的事情。 因此，我们find一个新的状态M ，它是D和F的混合， D和M的差别与+f相似，从F到M的差别与-e相似。 它看起来像这样：
-e +f' .---- D ----. / \ EM \ / '---- F ----' +f -e'
+f delta变成+f' ， -e delta变成-e' 。 这只是一个正常的三路合并，但效果很有趣：我们已经将F应用到D而不是E ！
合并之后， M到F的第二个父项被删除：
-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：我觉得有两个几乎完全相同的分支是很难看的。
