Mercurial,冲突,合并,后来进一步发生冲突,Mercurial 还记得最初的解决方案吗?
想象一下这样的场景:
- Alice 和 Bob 都克隆了一个中央主 Mercurial 存储库,其中包含 1 个文本文件
- Alice 和 Bob 都对文件中的同一行进行了更改,并将
- Bob 推送回中央存储库,但不是 Alice
- Alice 现在拉取进入她的存储库,注意到她现在有两个头,并合并
- 由于合并是冲突,她解决了冲突
- Alice 然后提交但不推送
- Bob 现在在文件的其他位置(即,与初始更改相差甚远)并提交,并推送
- Alice,在她的合并文件中,在 Bob 刚刚更改的同一位置进行类似的更改,并提交
- Alice 拉取,并发现另一个双头存储库,她合并了
这是一个不同的视图 场景的
(“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 所做的任何更改、她的初始更改(与 Bob 的更改相冲突)、她的合并以及她的最新更改(与 Bob 的最新更改相冲突) 。
如果我只是简单地将 Bob 的文件版本和 Alice 的文件版本提供给任何合并程序,它会将这两个更改标记为冲突。
换句话说,冲突工具会尝试要求 Alice 解决原始冲突和新冲突,还是仅解决最新冲突?
我猜测(我还没有尝试过这个,仍在尝试构建某种测试脚本来测试这个问题)Mercurial 只会要求 Alice 解决最新的冲突。
如果我将 Mercurial 配置为使用第 3 方差异/合并程序会怎样?这仍然适用吗?例如,我已将我的安装配置为使用 Beyond Compare,这两个文件(Bob 仅进行了更改,爱丽丝的更改+合并决议)是在有或没有初始决议的情况下给出的?换句话说,如果使用 Beyond Compare,这里也会发生正确的事情(假设它确实发生了。)
Imagine this scenario:
- Alice and Bob both clones a central master Mercurial repository, containing 1 text file
- Both Alice and Bob makes a change to the same line in the file, and commits
- Bob pushes back to the central repository, but not Alice
- Alice now pulls into her repository, notices she now has two heads, and merges
- Since the merge is a conflict, she resolves the conflict
- Alice then commits but does not push
- Bob now makes further changes to the file, in some other location of the file (ie. nowhere near the initial changes) and commits, and pushes
- Alice, in her merged file, does a similar change in the same location Bob just changed, and commits
- Alice pulls, and discovering yet another dual-headed repository, she merges
Here's a different view of the above scenario
(the numbers after "CHANGE" means that the person changed "portion X" of the file. If both users changed the same portion, we have a merge conflict ahead, if they changed different, not as much)
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 ???
At this point, my question is this:
- Will the merging tools take her first merge resolution into account? Since Bob never pulled in Alice's changes, his copy is still void of any of the changes Alice has made, her initial change (which was in conflict with Bob's), her merge, and her latest change, which is in conflict with Bob's latest change.
If I had simply taken Bob's version of the file, and Alice's version of the file, and given to any merge-program, it would flag both changes as in conflict.
In other words, will the conflict tool try to ask Alice to resolve both the original conflict and the new one, or only the latest one?
I'm guessing (I haven't tried this, still attempting to build some kind of test script to test this problem) that Mercurial will only ask Alice to resolve the latest conflict.
What if I configure Mercurial to use a 3rd party diff/merge program? Will this still apply? For instance, I have configured my installation to use Beyond Compare, will the two files (Bob's with only his changes and Alice's with her changes + the merge resolution) be given with or without the initial resolution present? In other words, if using Beyond Compare, will the correct thing happen here too (assuming it does at all.)
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
Mercurial 只需要解决最新的冲突,并且这可以与外部变更工具配合良好。
当 Alice 进行第二次合并时,她将自己之前的合并与 Bob 的新增量合并,并且只需要重新集成该更改。
顺便说一句,图表非常清晰。谢谢
Mercurial will require only that the latest conflict be resolved, and that will work fine with external change tools.
When Alice does her second merge, she's merging her own previous merge with bob's new delta and only that change needs to be integrated anew.
Really clear diagram, BTW. Thanks
它只会要求 Alice 更改最新的冲突。
原因如下:
她已经有来自 BOB 的 CHANGE 1,它在她的历史记录中,因此不会再次尝试更改该代码。有用。
It's only going to ask Alice to change the latest conflict.
The reason for this is as follows:
She already has CHANGE 1 from BOB it's in her history so it won't try to change that code again. It works.