如何解决涉及分支的 Mercurial case-folding 冲突？

Question

今天我去将一个分支合并回一个旧分支，并被告知由于 case-folding 冲突我无法更新到原始分支。

我的 repo 看起来有点像这样：

• 默认分支，修订版 1：添加大多数文件。
• 默认分支，修订版 2：添加文件 xyz 和 XYZ。大概是在Linux机器上完成的。这是 2008 年的事了。
• 默认分支修订 3-35：各种其他更改，没有问题
• 修订版 36：添加了新功能分支
• 功能分支，修订版 71：在 Windows 上通知 Sourcetree 报告 xyz 已删除，所以我提交了它，它变成了......
• 功能分支，修订版 72：这是明确删除 xyz 和 XYZ 的更改

此时，我想将功能分支合并回默认值，但是当xyz 根本不在存储库中时，它不会让我更新回版本 71 或除修订版 1 之外的任何其他版本。显然，从 2 到 71 的每个变更集都被这 2 个文件“污染”了，我只能在我的 Windows 和 Mac 机器上检查为 1。

通常建议的解决方案 - https://www.mercurial-scm.org/wiki/FixingCaseCollisions - 不起作用：它说 “hg 状态应该显示状态为 'R' 的麻烦文件和状态为 '!' 的所有其他文件”，但是当我按照这些步骤操作时，它实际上会显示状态为“M”的所有其他文件，这显然不是我想要的，并且意味着如果我继续操作会发生一些数据丢失。

此外，我怀疑我永远无法在 Windows 或 MacOS 上执行所需的合并，因为我需要修订版 35 处于可用状态，然后才能将任何内容拉入其中。

有什么我可以在这里解决的吗？我所有的文件都是安全的，我也愿意丢失 xyz 文件中的所有数据和修订以使这个 repo 再次工作，但我真的不希望完全丢失 repo 和更改日志。

Answer 1

我找不到合适的解决方法，所以我不得不借用一个 Linux 机器来获得一个区分大小写的文件系统。然后修复是：

1. 将整个存储库复制到安装了 Mercurial 的 Linux 计算机上。
2. 恢复/更新到默认分支上的最新版本，该分支在工作副本中有两个名称冲突的文件，hg rename 它们的名称没有冲突。此后重新应用任何其他更改。
3. 更新到另一个分支上的修订，做同样的事情。
4. 正常执行合并。
5. 将 repo 和工作目录复制回 Windows。
6. 删除/重命名/修改 2 个重命名的文件，以便只保留 1 个，使用所需的任何名称。

第 4 步和第 5 步可能按任意顺序完成。

Answer 2

我已经有一段时间没有这样做了，但我过去曾使用 convert 扩展程序 来清理 Windows 上的大小写折叠。

注意：我假设这本质上是一个私有存储库，您可以独占访问它。如果是这种情况，那么这种方法将起作用。 （即使不是这种情况，这在技术上仍然有效，但您必须将其作为新的 repo 发布给其他人，因为下面描述的转换会生成所有新的变更集 ID。）

您可以使用转换为 Mercurial 的扩展程序和 filemap 选项来执行此操作。

Convert 可以...在转换过程中重命名文件，当您 通过 --filemap 选项为其提供映射。

文件映射是一个指定要包含哪些文件的文件， 重命名或省略。

每一行可以包含以下指令之一： ...

rename from/file to/file

...

重命名指令重命名文件或目录。从一个重命名 子目录进入存储库的根目录，使用 .作为通往 重命名为。

执行此操作的命令行类似于：

hg convert--filehmap filemap.txtpath\to\source\repopath\to\converted\repo

filemap.txt 必须包含以下内容：

rename path\to\XYZ path\to\xyz_which_was_uppercase

转换过程应该重命名所有分支上 XYZ 的所有“实例”，因此我认为涉及分支的事实变得无关紧要。

Documentation.

Answer 3

正如 OP 所述，有关管理所描述类型的案例冲突的主要指导资源是 https://www.mercurial-scm.org/wiki/FixingCaseCollisions

那里给出的指示可能不够清楚，所以这里是基于那里给出的程序之一的带注释的成绩单。

我们从一个名为“repo”的存储库开始，它有两个文件：a.txt 和 A.txt。在远程机器上：

REMOTE_MACHINE $ hg files
A.txt
a.txt

现在让我们假设repo 以某种方式被克隆到本地计算机（发生折叠问题的计算机）。这可能是使用如下命令完成的：

$ hg clone --noupdate "ssh://REMOTE/DIRECTORY/repo" # illustrative

如果您不想更改本地计算机上的 repo，那么您可以（例如）克隆它，如下所示：

$ hg clone --noupdate repo xrepo  # illustrative and optional 

现在 cd 进入要修改的仓库目录，例如

$ cd repo   # or perhaps: cd xrepo

您可能想要验证存储库的完整性：

$ hg verify

接下来是两行黑魔法：

$ hg debugsetparents tip 
$ hg debugrebuildstate

此时，Mercurial 会认为您已签出 tip， 并且所有文件都丢失了（状态“！”）。在我们的例子中：

$ hg st -dram
! A.txt
! a.txt

现在我们将运行一些普通的 hg 命令来解决大小写折叠问题。让我们从手动提取感兴趣的文件开始：

$ hg cat a.txt > lc.a.txt
$ hg cat A.txt > uc.A.txt

现在从 repo 中删除两个有问题的文件：

$ hg -v remove --after a.txt A.txt
removing A.txt
removing a.txt

（上面的--after 选项实际上指示 Mercurial 处理被（从存储库）删除的文件不在磁盘上的事实。）

现在我们恢复正常了。我们可能想签入我们重命名的文件：

$ hg -v add lc.a.txt uc.A.txt
adding lc.a.txt
adding uc.A.txt

$ hg st -dram
A lc.a.txt
A uc.A.txt
R A.txt
R a.txt

$ hg commit --message "renamed a.txt to lc.a.txt and A.txt to uc.A.txt"
$ hg files
lc.a.txt
uc.A.txt

$ cat lc.a.txt
lowercase a
$ cat uc.A.txt
uppercase A
$

# Verify that the original files are still there:
$ hg files --rev 0
A.txt
a.txt

此时，要检查所有其他文件，您可以运行：hg revert --all