保留窯/ 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個小時內完成整個事情。 漫長的一天，但值得為它大大改善的存儲庫結構和清理的代碼。

現在一切都應該如此。 希望這會對其他用戶有所幫助。 如果您有類似的問題，並希望從我的經驗中獲得更多見解，請隨時發表評論。