Mercurial合并产生标记为已修改但二进制相等的文件

Question

我正在进行合并,我已准备好在这一点上提交,但我在TortoiseHg中的提交对话框显示许多文件已修改,但当我向父母传达时,它表示所有文件都是二进制相等的.

• 我没有并且从未启用过eol扩展.
• 没有任何更改,文件仍然注册为已修改.
• hg父母显示两个父母的文件.

• hg stat将文件显示为已修改,例如

  c:\Projects\MyProject>hg stat Authorization\AuthorityGroups.cs  
  M Authorization\AuthorityGroups.cs  
  

• hg diff --git没有显示任何内容,例如

  c:\Projects\MyProject>hg diff --git Authorization\AuthorityGroups.cs   
  c:\Projects\MyProject>   
  

我在两个不同的克隆上的两台不同的机器上试过这个,我看到了同样的事情.

关于我如何诊断或解决这个问题的任何其他想法？显然有些事情发生了变化,但如果它没有显示在hg diff --git我怎么能确定那可能是什么？

更新2014/12/10:

我已经对两个父修订版的历史做了更多检查,我想我明白为什么它会变得混乱.

• 默认情况下,我们在修订版1中添加了原始父文件.
• 在Apple分支上,文件已重命名以将其移动到新位置.
• 在Orange分支上添加了文件以将其移动到同一个新位置.

因此,两个分支上的文件是二进制相同且位于同一位置,但可能Mercurial将其标记为要合并的差异,因为它们通过明显不同的方式到达那里.

那么问题就变成了:

有没有办法回顾性地修复被视为添加和删除长期提交的变更集的移动(新的提交会很好,但我无法编辑历史记录),或者我只需要让它通过合并？

Answer 1

有没有什么方法可以追溯修复被视为长期提交变更集上的添加和删除的移动（新提交就可以了，但我无法编辑历史记录）

嗯……有点。更新到最新的 Orange 提交，其中文件具有旧名称（hg bisect如果您不确定具体发生时间，可以使用它来查找它），hg rename对新名称进行操作，提交，然后将其合并到当前的 Orange 中头。Mercurial应该足够聪明，能够将文件注册为正确重命名的文件，并且不会导致冲突（我们知道这一点是因为更复杂的 Apple/Orange 合并没有）。

或者我只需要让它在合并中通过？

这更容易。Mercurial 的合并算法相当聪明。它可以很好地处理这样的情况。

除非您有第三个分支，其中的文件从未移动过，否则第二个选项不太可能导致问题。如果你确实有这样的分支，只要将它合并到 Apple 重命名的后代（或从这样的后代合并）就应该没问题。主要的困难在于与 Orange 分支的合并。