问题描述
最近在维护Mercurial中的发行分支时，有一些关于跳过更改的问题.例如:
There've been several questions recently about skipping changes when maintaining release branches in Mercurial. For example:
- 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
transplantwould have generated patches out ofF::J, and then applied them ontoD, butgraftis 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'andM1? - 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中使用嫁接的后果的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！