mercurial - merge merge 选择了错误的更改，解决此错误的正确方法是什么？

Question

对我们的.vcproj进行了更改，以解决构建计算机上的问题(更改集1700)。后来，开发人员将他的更改(从1710到1715的更改)合并到了主干中，但是轻巧的自动合并覆盖了1700年以来的更改。我认为这是因为他选择了错误的分支作为合并的“父级”(请参阅​​第1部分)。问题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文件特别容易出现此问题，因为开发人员并未很好地理解它们，因此，如果确实出现冲突，它们将不确定如何处理。我的猜测是发生了这种情况，您的开发人员只是将其还原为他 checkin 的修订。

至于第1部分...

在这种情况下该做什么在很大程度上取决于您的开发过程。您可以剥离合并变更集并重做，尽管如果已经有很多人拉过合并变更集将无法很好地工作，并且如果已经基于该基础检查了许多变更集，则合并集将特别糟糕。在合并变更集上。

您也可以检入新的更改来解决合并问题。

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

在我看来，您的帖子语气表明您在组织中可能对此问题有某些政治看法，人们将此错误归咎于Mercurial的频繁合并。因此，我将指出，任何变更控制系统都可能存在此问题。例如，对于Subversion，每次开发人员在工作目录中有未完成的更改时进行更新时，他们都在进行合并，而任何合并都可能产生这种问题。