縮小汞回購規模（特別是清單）

Question

我們目前正在嘗試將Merurial（在這種情況下為Kiln的較早版本）遷移到BitBucket，我們立即遇到大小問題（如果您不知道，BitBucket施加了相當大的2gb回購限制-我們碰巧碰到了）。

無論如何，我已經清理了過去的罪過：

• 使用帶有文件映射的轉換（刪除不應在存儲庫中的二進制文件/靜態文件）
• 為不應在主倉庫中的其他事物創建單獨的倉庫
• 嘗試使用generaldelta減小大小（根據https://www.mercurial-scm.org/wiki/ScaleMercurial ）
• 使用分支圖嘗試合並舊分支及其關聯的變更集

即使經過這些步驟，我仍然有一個非常大的清單文件，盡管為回購存儲的“數據”縮小到“可管理”的大小（〜600mb），但清單文件卻接近700mb。

一些其他信息：通常，我們按功能進行分支，並且對環境有兩個分支的跟蹤：

• 發布分支（部署到暫存然后部署）
• 默認分支（最初不發布，所有功能都先合並到此處，然后發布。此分支死掉，每兩周重生一次）

此工作流程的一個不同之處在於，默認值本身永遠不會合並到版本中（la gitflow / hgflow）。 這種單向流入默認值會導致問題嗎？

我們“只有” 120個開放的分支機構，這似乎是可以管理的嗎？

我顯然在這里缺少一些步驟（否則，回購協議就完全被取消了）。

Answer 1

僅供以后參考，我遵循上述Tim的建議。 我的完整腳本最終看起來像這樣：

hg --config format.generaldelta=1 clone --pull oldrepo oldrepo-generaldelta
hg --config format.generaldelta=1 clone --pull oldrepo-generaldata oldrepo-generaldelta2
hg convert --filemap filemap.txt oldrepo-generaldelta2 newrepo

正如Tim在他的鏈接答案中提到的那樣-第二個克隆的清單從大約700mb下降到了40mb。

我可以優化Mercurial克隆嗎？