当合并的两个分支对同一个文件进行更改时,Mercurial是否始终使用外部合并工具?
或者它首先看看它是否可以合并文件本身,如果它不能,那么只能向外部工具发送?
我问的原因是我(再一次)重读tutorial written by Joel Spolsky on Mercurial和他说的一件事,比较Subversion和Mercurial合并的方式是:
相比之下,当我们分别在Mercurial工作时,Mercurial正忙于保留一系列变更集。因此,当我们想要将我们的代码合并在一起时,Mercurial实际上有更多的信息:它知道我们每个人都改变了什么并且可以重新应用这些更改,而不仅仅是查看最终产品并试图猜测如何放置它在一起。
只有,我的经验告诉我,当两个分支对同一文件进行更改时,似乎涉及外部合并工具。因此,这不会导致上述论点不正确吗?
或者我应该解释如下:
有人可以对此有所了解吗?
修改:让我举个例子:
@echo off
setlocal
if exist repo rd /s /q repo
md repo
cd repo
hg init .
rem --- version 0 ---
echo 1 >test.txt
echo 2 >>test.txt
echo 3 >>test.txt
echo 4 >>test.txt
echo 5 >>test.txt
hg add test.txt
hg commit -m "v0"
rem --- version 1 ---
echo 1 >test.txt
echo 2 v1 >>test.txt
echo 3 >>test.txt
echo 4 >>test.txt
echo 5 >>test.txt
hg commit -m "v1"
rem --- version 2 ---
hg update 0
echo 1 >test.txt
echo 2 >>test.txt
echo 3 >>test.txt
echo 4 v2 >>test.txt
echo 5 >>test.txt
hg commit -m "v2"
rem --- merge ---
hg update 1
hg merge 2
首先创建一个包含以下内容的文件:
1
2
3
4
5
然后将其更改为:
1
2 v1
3
4
5
然后它返回到初始版本(changeset),并将其更改为:
1
2
3
4 v2
5
然后它试图将两者合并。
现在,根据(目前)单一答案,这不应该造成问题,因为这些变化没有冲突。
但是,此时,会调用Beyond Compare(我的外部合并工具)。
答案 0 :(得分:6)
mercurial合并和svn合并之间的最大区别在于mercurial合并算法可以访问被合并的两个修订版之间的最后共同祖先。如果您的历史记录是
A--B
\-C
svn会让您的合并工具在B和C上失败.Mercurial将使用A,B和C启动您的工具,而某些工具可以做得更好。
Mercurial在启动你的工具之前会做自己的内部合并,它使用A,B和C来做出一些明显的选择。您可以通过更改工具的premerge
设置来关闭它。
你的测试没有给出很好的结果,因为你正在与自己的祖先合并2。如果您在创建变更集2之前执行了hg update 0
,那么您将拥有这样的实际分支历史记录:
@ changeset: 2:790856e061f4
| tag: tip
| parent: 0:bfba1d8f77af
| user: Ry4an Brase
| date: Fri Jul 09 16:50:34 2010 -0500
| summary: added v2
|
| @ changeset: 1:7a9c581561b6
|/ user: Ry4an Brase
| date: Fri Jul 09 16:50:16 2010 -0500
| summary: added v1
|
o changeset: 0:bfba1d8f77af
user: Ry4an Brase
date: Fri Jul 09 16:49:29 2010 -0500
summary: first
然后当你hg merge
时,你会得到:
1
2 v1
3
4 v2
5
没有启动合并工具。
答案 1 :(得分:3)
仅在存在需要解决的冲突的情况下才会调用mergetool。对不同分支中的同一文件的更改构成了这种冲突。
除此之外,实际的合并算法不是基于变更集的,它的文件基于允许最佳合并结果。有关详细信息,请参阅Mercurial Wiki。
Mercurial会让您的合并取消注释,因此您有机会在合并变更集之前检查您的代码。