我们最近改用了Mercurial。一切都进展顺利，直到我们发生了两次失败的承诺变更事件。检查日志并没有让我们更聪明。
以下是一个例子。在（1）处提交的文件在（2）处恢复到先前的状态，即使合并中未提及这些文件。
我可以检查什么来理解文件还原的原因？
答案 0 :(得分：2)
此图中有三个有趣的变更集可以影响（2）合并：
当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} }}”。换句话说：三方合并有利于改变，并且会让修改获胜。
你可以找到
的祖先Y其中$ hg log -r "ancestor(p1(changeset-2), p2(changeset-2))"
是上面标有（2）的那个。当你说
在（1）处提交的文件恢复到（2）的先前状态，即使合并中未提及这些文件。
然后重要的是要理解“合并”只是一个快照，显示如何混合其他两个变更集。 “合并”中的更改是此快照与其两个父更改集之间的差异：
changeset-2这显示了合并变更集如何分别与其第一个和第二个父变量不同。我确信这些文件中有一个被提及 - 除非合并不是罪魁祸首。
当您检查三个变更集及它们之间的差异时，您可能会看到有人必须解决冲突（上面合并表中的第四行）并在此过程中的某个步骤选择了错误的文件。 / p>
答案 1 :(得分：1)
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选项）。一旦你有了 执行测试，将工作目录标记为好或坏，并平分 将更新到另一个候选变更集或宣布它 发现了糟糕的修改。