想象一下这种情况:
以上是上述情景的不同视图
(“CHANGE”之后的数字意味着该人改变了文件的“部分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 ???
此时,我的问题是:
如果我只是简单地使用了Bob的文件版本和Alice的文件版本,并将其提供给任何合并程序,那么它会将这两个更改标记为冲突。
换句话说,冲突工具是否会尝试让Alice解决原始冲突和新冲突,或者只解决最新冲突?
我猜测(我还没有试过这个,仍然试图构建某种测试脚本来测试这个问题),Mercurial只会要求Alice解决最新的冲突。
如果我将Mercurial配置为使用第三方差异/合并程序,该怎么办?这仍然适用吗?例如,我已将我的安装配置为使用Beyond Compare,是否存在初始分辨率,是否会给出两个文件(Bob只有他的更改和Alice的更改+合并解决方案)?换句话说,如果使用Beyond Compare,那么正确的事情也会发生在这里(假设它完全没有。)
答案 0 :(得分:5)
Mercurial只需要解决最新的冲突,并且可以使用外部更改工具。
当Alice进行第二次合并时,她将自己之前的合并与bob的新delta合并,只有这种变化需要重新整合。
真的很清楚图表,BTW。感谢
答案 1 :(得分:2)
只会要求Alice改变最新的冲突。
原因如下:
她已经从BOB改变了历史,所以它不会再尝试更改代码。它有效。