Question

我们最近改用了Mercurial。一切都进展顺利，直到我们发生了两次失败的承诺变更事件。检查日志并没有让我们更聪明。

以下是一个例子。在（1）处提交的文件在（2）处恢复到先前的状态，即使合并中未提及这些文件。

我可以检查什么来理解文件还原的原因？

revision graph http://i43.tinypic.com/1f8ruq.png

Answer 1

此图中有三个有趣的变更集可以影响（2）合并：

青色变换集未显示，但看起来就在图表下方。这是（2）
蓝色变更集：从底部开始的第五个，标记为“修复测试”。这是（2）的第二个父母。
父母的共同祖先：也未显示，将在下面进一步说明。奇怪的是，看起来teal变更集可能是共同的祖先，但Mercurial现在允许你在正常情况下进行这种退化合并。

当Mercurial进行合并时，这些是唯一三个变更集：您合并的两个头和它们的共同祖先。在三方合并中，逻辑现在是：

ancestor  parent1  parent2  =>  merge
X         X        Y            Y (clean)
X         Y        X            Y (clean)
X         Y        Y            Y (clean)
X         Y        Z            W (conflict)

阅读如下表：“如果祖先是X，第一个父亲也是X而第二个父亲是Y，那么合并将包含{{1} }}”。换句话说：三方合并有利于改变，并且会让修改获胜。

你可以找到

的祖先

其中$ hg log -r "ancestor(p1(changeset-2), p2(changeset-2))"是上面标有（2）的那个。当你说

在（1）处提交的文件恢复到（2）的先前状态，即使合并中未提及这些文件。

然后重要的是要理解“合并”只是一个快照，显示如何混合其他两个变更集。 “合并”中的更改是此快照与其两个父更改集之间的差异：

changeset-2

这显示了合并变更集如何分别与其第一个和第二个父变量不同。我确信这些文件中有一个被提及 - 除非合并不是罪魁祸首。

当您检查三个变更集及它们之间的差异时，您可能会看到有人必须解决冲突（上面合并表中的第四行）并在此过程中的某个步骤选择了错误的文件。 / p>

Answer 2

2处的合并是在一个非常古老的分支（深蓝色，在提交1之后从主线/绿色分支分叉）和一个更老的分支（淡蓝色，从提交之前的主线未同步）之间）

似乎2中的合并选择了错误的文件版本 - 从这里无法判断是否是工具选择了错误的文件版本，或者用户手动选择了错误的版本。

编辑添加：

为了帮助准确追踪2处更改的内容，您可以使用hg diff -r REV1 -r REV2，它会显示任意两个版本之间的逐行差异。

如果您知道在第1点和第2点之间的某个时间引入了错误，hg bisect可能会帮助您找出错误的确切来源：

hg bisect [-gbsr] [-U] [-c CMD] [REV]

细分搜索变更集
This command helps to find changesets which introduce problems. To use,
标记您知道的最早的变更集表明问题是坏的，然后标记   最新的变更集，可以解决问题。

Bisect会将您的工作目录更新为修订版以进行测试   （除非指定了-U / - noupdate选项）。一旦你有了   执行测试，将工作目录标记为好或坏，并平分   将更新到另一个候选变更集或宣布它   发现了糟糕的修改。

Mercurial提交消失了

2 个答案: