在Mercurial中使用嫁接的后果 [英] Consequences of using graft in Mercurial

问题描述

最近在维护Mercurial中的发行分支时，有一些关于跳过更改的问题.例如:

There've been several questions recently about skipping changes when maintaining release branches in Mercurial. For example:

• Mercurial:分支特定的更改在以后会继续出现虚拟合并
• 为什么一个分支机构中的Mercurial撤消会影响其他分支分支?

• Mercurial: Branch specific changes keep coming back after dummy merge
• Why are Mercurial backouts in one branch affecting other branches?

自从2.0版引入以来，我一直想知道如何使用graft来避免此问题.给定这样的修订树:

Since it was introduced in 2.0, I've wondered about using graft to avoid this problem. Given a revision tree like this:

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

假设我们需要创建一个发布分支，以跳过Evil更改E.

Suppose we need to create a release branch that skips the Evil change 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向合并而不是补丁.那么.......这是怎么工作的呢?为什么会更好?
• Q1: What just happened here? I can understand that transplant would have generated patches out of F::J, and then applied them onto D, but graft is said to use the 3-way merge rather than patches. So....... how does that work? Why is it better?

假设我现在修复了E，并将其合并到我的发行分支中.

Lets say I now fix E, and merge that into my release branch.

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

M1是直接合并；那里没什么特别的. M2是合并具有相同"(或至少等效)更改的分支.

M1 is a straight merge; nothing special there. M2 is merging branches which have "the same" (or at least equivalent) changes on.

• Q2:此合并是否只是使用D，J'和M1的常规三向合并?
• Q3:Mercury是否存储/使用了有关嫁接操作的额外信息以帮助合并?
• Q2: Is this merge just a normal 3-way merge using D, J' and M1?
• Q3: Has mercurial stored/used extra information about the graft operation to help it with the merge?

最后...

• Q4:这样的流程潜在的问题是什么?

推荐答案

当您更新到D和嫁接F::J时，Mercurial会运行许多合并.将从此合并开始:

When you update to D and graft F::J, Mercurial runs a number of merges. It will start with this merge:

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

如果我们为状态C和D之间的增量写+d，那么我们开始于:

If we write +d for the delta between the states C and D, then we start with:

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

将图形顺时针旋转90度，以上三向合并看起来像这样:

Turn the graph 90 degrees clockwise and the above three-way merge looks like this:

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

也就是说，我们假装以E开头，并应用-e的反义词来获取D.我认为是+e的反向补丁.从E开始，我们还使用正常增量+f进入状态F.这里没有什么奇怪的-我们已经在存储库中拥有所有状态(D，E和F).这样看来，很明显我们可以合并D和F.

That is, we pretend that we started with E and applied the opposite of -e to get to D. I think of as the reverse patch of +e. Starting in E we also went to state F with the normal delta +f. There's nothing strange here — we have all the states (D, E, and F) in the repository already. So seen like this, it's clear that we can merge D and F.

合并是完成钻石"的问题.因此，我们找到了一个新状态M，它是D和F的混合，其中D与M的差异类似于+f，并且F与M的差异与-e相似.看起来像这样:

Merging is a matter of "completing the diamond". So we find a new state M that is a mix of D and F and where the difference from D to M is similar to +f and the difference from F to M is similar to -e. It looks like this:

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

+f增量变为+f'，而-e增量变为-e'.这只是正常的三向合并，但效果很有趣:我们将F应用于了D而不是E！

The +f delta became +f' and the -e delta became -e'. This is just a normal three-way merge, but the effect is interesting: we've applied F onto D instead of E!

合并后，M到F的第二个父级将被删除:

After the merge, the second parent of M to F is dropped:

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

重申一下:我们已经将F的效果"复制到了D上，也就是说，我们发现了一个应用于D的增量(+f')与+f时具有相同的效果.已应用于E.我们可以将图稍微拉直以获得:

To reiterate: We have copied the "effect" of F onto D, that is, we have found a delta (+f') that applied to D give the same effect as when +f was applied to E. We can straighten the graph a bit to get:

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

结果是使用完整的三向机械将F嫁接到D上.

The result is that F is grafted onto D using the full three-way machinery.

• 问题1:这里发生了什么?那么.......这是怎么工作的呢?为什么会更好?

• Q1: What just happened here? So....... how does that work? Why is it better?

A1:因为合并机制考虑了重命名之类的问题，所以使用合并比使用补丁程序要好.

A1: Using merges is better than patches since the merge machinery takes things like renames into account.

第二季度:这种合并只是使用D，J'和M1的普通三向合并吗?

Q2: Is this merge just a normal 3-way merge using D, J' and M1?

A2:是的，嫁接不会改变图的拓扑.

A2: Yes, grafting does not alter the topology of the graph.

第三季度:是否已存储/使用了有关嫁接操作的额外信息以帮助进行合并?

Q3: Has mercurial stored/used extra information about the graft operation to help it with the merge?

A3:否.

问题4:像这样的流程有哪些潜在问题?

Q4: What are the potential problems with a flow like this?

A4 :从合并的角度来看，它应该可以正常工作.它将复制一些可能使人们感到困惑的历史.

A4: From a merge perspective it should work okay. It will duplicate some history which might be confusing for people.

这篇关于在Mercurial中使用嫁接的后果的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！