变化无常,冲突,合并,以后进一步的冲突,变化无常还记得最初的解决方案吗?

1. Alice和Bob都克隆了一个中央主Mercurial存储库,其中包含一个文本文件
2. Alice和Bob都对文件中的同一行进行了更改,并提交
3. Bob推回到中央存储库,但不是Alice
4. 爱丽丝现在把车开进仓库,注意到她现在有两个头,于是合并了
5. 因为合并是一个冲突,她解决了这个冲突
7. Bob现在对文件做进一步的更改,在文件的另一个位置(即不接近初始更改)并提交和推送
8. Alice在她的合并文件中,在Bob刚刚更改的同一位置做了类似的更改,并提交

下面是对上述场景的不同看法

(“变更”后的数字表示该人变更了文件的“X部分”。如果两个用户更改了相同的部分,则前面会有一个合并冲突,如果他们更改了不同的部分,则不会有太多)

    Alice                    Bob
    CLONE MASTER             CLONE MASTER
    -----------------------------------------
    CHANGE 1                               <-----+
    COMMIT                                       +-- upcoming merge conflict
    -----------------------------------------    |
                             CHANGE 1      <-----+
                             COMMIT
                             PUSH
    -----------------------------------------
    PULL                                   <-- Bob's change +1 head
    MERGE                                  <-- Attempt to get rid of extra head
    RESOLVE CONFLICT                       <-- Resolve merge conflict
    COMMIT
    -----------------------------------------
                             CHANGE 2      <-----+
                             COMMIT              +-- yet another merge
                             PUSH                |   conflict ahead
    -----------------------------------------    |
    CHANGE 2                               <-----+
    COMMIT
    PULL                                   <-- Bob's change, again +1 head
    MERGE                                  <-- Attempt to get rid of extra head
    RESOLVE ???

在这一点上,我的问题是:

• 合并工具会考虑她的第一个合并解决方案吗?由于鲍勃从未加入爱丽丝的更改,他的副本仍然没有爱丽丝所做的任何更改、她的初始更改(与鲍勃的更改冲突)、她的合并以及她的最新更改(与鲍勃的最新更改冲突)。

换言之,冲突工具会试图让Alice同时解决原始冲突和新冲突,还是只解决最新的冲突?

我猜( 我还没有尝试过,仍然试图构建某种测试脚本来测试这个问题 )那个反复无常的人只会要求爱丽丝解决最近的冲突。

如果我将Mercurial配置为使用第三方diff/merge程序呢?这还适用吗?例如,我已将安装配置为使用 Beyond Compare ,这两个文件(Bob的只有他的更改,Alice的有她的更改+合并分辨率)是在有或没有初始分辨率的情况下给出的?换句话说,如果使用 ,这里也会发生正确的事情吗(假设它确实发生了)