等一下，这会很粗糙。我正在尝试清理一个我只能描述为病态的 Mercurial 存储库，似乎最简单的“修复”是在两个分支之间交换一个目录。我不确定我是否能充分解释这种情况，但我会试一试。
我们有一个工具可以从大量输入中生成原始源代码。（数百或数千个输入文件，类似数量的输出文件。）然后根据需要手动调整和优化此输出，然后宣布准备部署。该工具在提供配置文件等的目录中运行。
就像是：
proj/.hg
/input
/output
/config-env
现在，发生的事情是使用了一个分支来进行调整，而不是（对我而言）共享 mq 方法的逻辑选择。（该团队当时并不了解 mq，大部分都接受过 CVS 培训，但值得称赞的是，他们正在努力改进工作流程。）
这就是它变得糟糕的地方。
命名分支是原始输出分支，默认分支是手动调整分支。
不断创建工具的输出，hg update raw然后hg merge尝试将工具改进合并到原始分支中，然后将其合并回“默认”分支以合并改进和先前的手补丁，使用合并失败列表作为需要进一步手动编辑的选择列表。
即，两个分支之间的这种疯狂循环使开发成为脆弱和错误的小噩梦。这就是我要清理的。我想要的是默认分支是原始输出，以及一个包含手动补丁的新“部署”分支，合并只有一种方式，从默认到部署。仍然不是最优的，IMO，但在我能够说服权力认为 mq 是要走的路之前，这是一个相当大的改进。
但。还有更多。随着时间的推移，config-env 和输入目录发生了变化，但这些变化并没有保持干净并且在两个分支之间保持同步。对 input 和 config-env 的更改在默认分支上，但匹配的原始输出在 raw 分支上，过时的输入和 config-env 并不真正属于那里。我询问过是否删除过时的文件是不必要的，但有人认为我们需要保留它们。出于这个原因，我只想交换两个分支之间的输出目录。
我考虑过类似的事情，hg convert --branchmap swap.txt --filemap only-output.txt --datesort但后来意识到我只会在结果仓库中获得输出目录。我也许可以将两个分支的输出目录从字面上剥离到它们自己的存储库中，并交换分支名称，然后将两个存储库合并在一起（无输出，输出与交换分支），但我想也许这里有人会有更好的主意。
当然，我的目标是有一个带有 mq 补丁列表的分支来存储手补丁，并且该补丁列表是共享存储库的一部分，但是婴儿步骤是有序的。
如果推送到了紧要关头，我认为我们可以消除两个分支上输出目录的大部分历史记录，但我们确实需要在两个分支上保留某些标记的版本。