保留窑/ Fogbugz历史的Mercurial存储库清理

Question

TL; DR版本：是否可以在不破坏窑炉/福布兹历史的情况下重组水银回购协议？ 还是我必须重新开始？

---

我有一个真正的混乱存储库，需要进行一些认真的清理，并且正在尝试找出最佳方法。 目标是完全删除一些文件-它们永远都不应出现在任何提交中-移动一些目录并将一个目录拆分到一个完全独立的存储库中。 我知道，我知道-您不应该能够更改历史记录。 但是，在这种情况下，它要么是更改历史记录，要么是从头开始使用新的存储库。

有问题的存储库在Mercurial中管理，而远程存储库则在Kiln中托管。 在Fogbugz中跟踪问题。 由于有一些提交链接处理规则，因此，提交消息中对问题（案例）编号（如Case 123 ）的任何引用都将转换为指向相关Fogbugz案例的链接。 反过来，提到的案例在提交的消息后附加了一个注释。

当前结构

当前项目文件结构如下：

- /
    +- includes/
    |   +- functions-related-to-abc.php
    |   +- functions-related-to-xyz.php
    |   +- class-something.php
    |   +- classes-several-things.php
    |   +- random-file.php
    |   ...
    |
    +- development/
    |   +- a-plugin-folder/
    |   |   +- some-file.php
    |   |   +- file-with-sensitive-and-non-sensitive-info.php
    |   |   ...
    |   |
    |   +- some-backend-functions-related-to-coding.php
    |   ...
    |
    +- index.php
    +- test-config-file.php
    ...

目标结构

我想要的结构是这样的：

- /
    +- build/
    +- doc/
    +- src/
    |   +- functions/
    |   |   +- abc.php  // renamed from includes/functions-related-to-abc.php
    |   |   +- xyz.php  // renamed from includes/functions-related-to-xyz.php
    |   |   ...
    |   |
    |   +- classes/
    |   |   +- something.php       // renamed from includes/class-something.php
    |   |   +- several-things.php  // renamed from includes/classes-several-things.php
    |   |   ...
    |   |
    |   +- view/
    |   |   +- random-file.php  // formerly includes/random-file.php
    |   ...
    |
    |   +- development/
    |   |   +- some-backend-functions-related-to-coding.php
    |   |   ...
    |   +- index.php
    |   ...
    |
    +- test/
    ...

a-plugin-folder将移至其自己的单独存储库。 不再在存储库中完全跟踪test-config-file.php 。 理想情况下，在我处理分支的同时，我还将对其进行一些小的修剪和重命名。

在我的梦想世界中，无论如何都可以始终跟踪file-with-sensitive-and-non-sensitive-info.php敏感信息.php的文件，但是随着敏感信息（几个密码）被提取到不受版本控制的配置文件中。 我意识到这可能是一厢情愿的想法。

我目前的想法

我目前的想法是，我的愿望清单基本上是不可能的：从现在开始，我可以创建新的，结构正确的存储库，但不能保留更改历史记录，也不能进行需要进行的重大结构更改。 在这种情况下，我应该采用当前的代码库，按照自己的方式进行重组，并将其提交为两个新存储库（根存储库和插件存储库）的变更集1。 然后，我只需将旧存储库的副本备份在某处以供参考。 主要缺点：（1）我失去了所有历史，并且（2）Kiln和Fogbugz对历史提交的交叉引用都是吐司。

我的问题

所以，这是一个问题：有什么办法可以做我想要的事情-重组，拉出一些文件并使所有内容看起来都很漂亮-而又不会丢失我的所有历史记录？

我考虑过使用hg convert扩展 ，大量使用filemap ， splicemap和branchmap选项。 我看到的这种方法的问题包括：（1）破坏所有先前的版本，（2）先前的版本中根本不包含具有file-with-sensitive-and-non-sensitive-info.php （或留在其中，这会失败）要点），以及（3）使得许多提交消息在它们引用文件名或存储库结构的程度上大为错误。 换句话说，与仅启动干净，结构正确的存储库相比，我不确定此选项能给我带来多少好处。

我还考虑了一种极端的选择：通过遍历每个现有提交来编写某种自定义脚本来构建新的存储库，将敏感信息从file-with-sensitive-and-non-sensitive-info.php敏感信息的file-with-sensitive-and-non-sensitive-info.php剥离出来，重写提交消息到必要的程度，并提交所有内容的修订版。 从理论上讲，这可以解决我所有的问题，但是要以重新发明轮子为代价，并且可能要花费大量的时间。 我正在寻找不等同于编写整个hg扩展的东西。

编辑：我正在考虑创建一个空的存储库，然后编写一个脚本，该脚本使用hg export和hg import将变更集带到一个变更集，并在必要时进行编辑以将敏感信息（例如密码）从文件中剥离。 是否有理由不起作用？

Answer 1

编辑：我最终采取了一种不同于下面描述的方法。 我的其他答案解释了我最终所做的事情。 也就是说，我对如下所述的插件仍然非常感兴趣，因此，如果我有时间做它或其他人想参与该项目，那么我将保留此帖子以供参考。

---

我已经确定可以使用导入，导出以及在存储库历史记录中的适当位置进行一些修补来实现这一点。

算法

该算法的简短版本如下所示：

1. 创建一个新的仓库

2. 遍历现有存储库的变更集，执行以下操作：

   1. 从旧存储库导出变更集
   2. 将变更集导入到新的存储库中，而无需提交
   3. 对提交消息和/或敏感文件进行必要的编辑
   4. 在新存储库中提交变更集，保留（可能已修改）提交消息和其他元数据

3. 交换旧存储库和新存储库

注意事项：

• 显然，与所有历史记录编辑一样，这仅适用于非第三方未拉出的非公共存储库。
• 第2步可以而且应该高度自动化，以批量处理变更集，而无需进行任何编辑。
• 每当需要更改时，都必须停止执行。

使它工作

我有一个非常基本的概念批处理文件证明，证明了这可以工作。

我正在研究Mercurial插件，以使其尽可能简单。 话虽如此，如果有人的话，我仍然愿意接受更好的建议。

Answer 2

我能够实现自己的目标。 我最终要做的是：

• 首先，我通过消除所有分支和合并并将存储库转换为单行提交来“整理”（拉直）存储库。 我必须这样做，因为hg histedit （整个清理的关键）不适用于包含合并的历史记录。 我可以接受，因为在此特定存储库中没有真正有意义的分支或合并，并且相关历史中只有一位作者。 我可能可以保留分支，并在以后根据需要再次合并，但这对我来说更容易。 为此，我使用了hg rebase和MQ扩展。 （特别感谢@tghw 这个非常有用的答案 ，它帮助我第一次了解了MQ的真正工作原理。）

• 接下来，我用hg convert从原始存储库中创建了几个存储库-每个我需要放入自己的存储库中的库/插件一个，一个用于其余代码的主存储库。 在此过程中，我根据需要使用--filemap和--branchmap重新组织所有内容。

• 第三，我在每个新存储库上使用hg histedit来（1）根据需要清理不相关的提交消息，以及（2）删除敏感信息。

• 第四，我将所有新存储库推送到Kiln，Kinn使用与原始存储库相同的规则将它们自动链接到FogBugz案例（例如，提交消息中的Case 123创建到FogBugz案例＃123的链接）。

• 最后，我“删除”了Kiln中的原始存储库。 到目前为止，Kiln尚未真正永久删除存储库，尽管我已经提出了一个使之成为可能的用例。 相反，它取消了FogBugz案例的链接，并将“已删除”的存储库放入冷库中。 帐户管理员可以还原它，但是它是不可见的。

总共花了大约10个小时将原始存储库分成6个部分，并对每个部分进行清理。 其中一些是学习曲线； 如果我不得不再次做的话，我大概可以在6个小时内完成整个事情。 漫长的一天，但值得为它大大改善的存储库结构和清理的代码。

现在一切都应该如此。 希望这会对其他用户有所帮助。 如果您有类似的问题，并希望从我的经验中获得更多见解，请随时发表评论。