0

我们最近切换到 Mercurial。一切都进行得很顺利，直到我们有两次提交的更改丢失的事件。检查日志并没有让我们变得更聪明。

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

我可以检查什么来了解文件恢复的原因？

修订图

4

2 回答 2

3

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

  • 青色变更集：未显示，但看起来就在图表下方。这是 (2) 的第一个父级
  • 蓝色变更集：从底部数第五个，标记为“修复测试”。这是 (2) 的第二个父节点。
  • 父母的共同祖先：也没有显示，将在下面进一步说明。奇怪的是，蓝绿色变更集看起来可能是共同祖先，但 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，那么合并将包含Y”。换句话说：三路合并有利于改变，会让修改获胜。

你可以找到祖先

$ hg log -r "ancestor(p1(changeset-2), p2(changeset-2))"

changeset-2上面标有（2）的那个是哪里。当你说

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

那么重要的是要了解“合并”只是显示如何混合其他两个变更集的快照。“在”合并中所做的更改是此快照与其两个父更改集之间的差异：

$ hg status --rev "p1(changeset-2):changeset-2"
$ hg status --rev "p2(changeset-2):changeset-2"

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

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

于 2012-01-31T09:33:21.247 回答
1

2 处的合并介于一个非常旧的分支（深蓝色，在提交 1 之后从主线/绿色分支分叉）和一个更旧的分支（浅蓝色，自提交 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 选项）。执行测试后，将工作目录标记为好或坏，然后 bisect 将更新到另一个候选变更集或宣布它找到了错误的修订。

于 2012-01-31T04:10:52.523 回答