Mercurial 合并选择了错误的更改，解决此问题的正确方法是什么？

Question

对 .vcproj 进行了更改以修复构建计算机上的问题（变更集 1700）。后来，一名开发人员将他的更改（更改 1710 到 1715）合并到主干中，但是善变的自动合并覆盖了 1700 中的更改。我认为发生这种情况是因为他选择了错误的分支作为合并的“父分支”（请参阅​​第问题2）。

1) 解决此问题的“正确”多变方法是什么，考虑到在所有合并的文件中，只有一个文件合并不正确，以及

2) 开发人员应该采取哪些不同的措施来确保不会发生这种情况？我们有什么方法可以强制执行“正确”的方式吗？

编辑：我可能不太清楚发生了什么。开发人员 A 修改了 .vcproj 文件中的一行，删除了编译器的选项。他的签入变成了变更集 1700。开发人员 B 在前一个父级（假设变更集 1690）工作，对项目的完全不同部分进行了一些更改，但他确实接触了 .vcproj 文件（只是与开发人员 A 所做的更改相差甚远）。当开发人员 B 合并他的更改（更改为 1710 到 1715）时，合并过程会覆盖 1700 中的更改。

为了解决此问题，我只需重新修改 .vcproj 文件以再次包含更改，然后将其签入。我只是想了解为什么 Mercurial 认为它不应该保留 1700 中的更改，以及是否有“官方”方法来解决此问题。

编辑第二个：开发人员 B 发誓 Mercurial 合并了 .vcproj 文件，但没有提示他解决冲突，但当然有可能他只是记错了，在这种情况下，整个练习都是学术性的。

Answer 1

我将首先解决您问题的第二部分......

如果存在冲突，自动合并工具应该迫使程序员决定合并如何发生。但一般的假设是冲突将涉及对同一组行的两次编辑。如果由于对彼此不靠近的行的编辑而产生冲突，自动合并将愉快地选择这两个编辑，并且会出现错误。

合并工具始终正确合并的一般情况很难解决，而且当前的技术确实无法解决。下面是我在 C 语言中的意思的一个例子：

int i;  // Someone replaces this with 'short i' in one changeset stating
        // that a short is more efficient.

// ...  lots of code;

// Someone else replaces all the 65000s with 100000s in another changeset,
// saying that more precision is needed.
for (i = 0; i < 65000; ++i) {
    integral_approximation_piece(start + i/65000.0, end + (i + 1) / 65000.0);
}

没有任何合并工具能够捕获这种冲突。该工具必须实际编译代码才能看到代码的这两部分彼此有什么关系，虽然在这种情况下这可能就足够了，但我可以构建一个需要运行代码的示例，并且检查结果以发现冲突。

这意味着您真正应该做的是在合并之后严格测试您的代码，就像在任何其他更改之后一样。绝大多数合并将导致开发人员必须解决的明显冲突（即使该解决方案通常相当明显），或者将干净地合并。但是，极少数不适合任一类别的合并无法轻松地以自动化方式处理。

这也可以通过鼓励本地化的开发实践来解决。例如，一个编码标准规定“变量应该在它们使用的地方附近声明”。

我猜测 .vcproj 文件特别容易出现此问题，因为开发人员不能很好地理解它们，因此如果确实出现冲突，他们将不确定如何处理它们。我的猜测是，这种情况发生了，您的开发人员只是恢复了他签入的修订版本。

至于第 1 部分……

在这种情况下该怎么做很大程度上取决于您的开发过程。您可以删除合并变更集并重做它，尽管如果很多人已经拉取了它，那么这不会很好地工作，并且如果已经签入了许多基于基于的变更集，那么它的工作效果会特别差。在合并变更集上。

您还可以签入修复合并问题的新更改。

这些基本上是你的两个选择。

在我看来，您帖子的语气表明您的组织中可能存在一些围绕此问题的政治观点，人们将此错误归咎于 Mercurial 的频繁合并。所以我会指出任何变更控制系统都可能存在这个问题。例如，就 Subversion 而言，每当开发人员在其工作目录中存在未完成的更改时进行更新时，他们都会进行合并，并且任何合并都可能会出现此类问题。

Answer 2

在 Mercurial 中，合并没有单个父级，根据定义，它有两个且只有两个父级。当有人合并时，他们会做出两个选择：

1. 哪两个变更集将构成这两个变更
2. 这些变更集中哪个将是左父级，哪个将是右父级

在这两个问题中，第一个问题非常重要，第二个问题非常重要根本不重要，尽管我花了一段时间才明白这一点。

您可以使用 hg update X 选择左父级。这会更改 hgparents 的输出（或在较新版本中的 hgsummary），并本质上确定合并之前工作目录中的内容。

您可以使用 hg merge Y 选择右父项。这就是说将 X（工作目录的父目录）与变更集 Y 合并。作为一种特殊情况，如果您的存储库中只有两个头，并且您的父目录已经是其中之一，那么 Y 将默认为另一个。

我必须查看结果图才能知道开发人员做了什么，但他有可能在调用合并之前没有更新到一个头或另一个头，这将使他将一个头与历史上的某个点合并。

如果您的开发人员为合并选择了正确的父级，那么左与右并不重要——唯一真正的区别是当使用 hg diff 或 hg log -p< /code> 或其他显示合并变更集补丁的命令，它是相对于左父级显示的。然而，这主要只是显示方面的一个因素。从功能上来说，它们几乎相同。

假设您的开发人员选择了正确的变更集，那么他应该做的是在提交之前测试合并的结果。合并是软件开发，不是恼人的 VCS 副作用，并且在提交之前不进行测试就是错误。

修复

要修复此问题，只需重新正确进行合并即可。使用 hg update 设置一个父级，使用 hg merge 选择另一个。确保您当前的工作目录正确，然后提交。您可以使用 hg strip 或更好的东西摆脱他的错误合并，只需在更新后使用 hg commit --close-branch 关闭他的分支即可。

避免

你说“mercurial auto-merge”，但mercurial并没有真正自动合并。它会执行预合并，这是对明显更改的极其谨慎的组合，但它非常小心，如果每个合并父级在同一区域中添加代码，它甚至不会为您合并，因为它不知道是哪个您希望首先拥有的代码块。

您可以使用合并工具配置选项完全或逐个文件地禁用此预合并：

https://www.mercurial-scm.org/wiki/MergeToolConfiguration?highlight=premerge