2010-10-29 61 views
7

比方說,我創建一個存儲庫,添加x文件並提交。說初始提交後大小爲a Mb。Mercurial存儲庫隨着時間的推移如何增長?

  • 有什麼方法可以估計一年內存儲庫的容量有多大?

  • 如果代碼行數量增加了10%,版本庫是否會相應地增長?

  • 如何提交,分支,標籤等因素到存儲庫大小?

  • 同一年10000個提交會使存儲庫增長(明顯)超過1000次提交?

  • 也許我的問題是錯誤的措詞?

+0

這實際上應該是兩個問題 - 一個關於git和一個關於mercurial的問題。當然,他們都是DVCS,但他們不是一回事。它們沒有相同的內部結構,它們不會完全相同。 – Cascabel 2010-10-29 15:20:07

+1

@Jefromi:他們都使用增量化,他們都存儲完整版本每N deltas,他們都壓縮增量和完整版本。 – 2010-10-29 16:49:50

+1

@Jakub:夠公平的。我對mercurial並不完全有信心,只知道它是相似的。當然,考慮到問題的提出,OP幾乎肯定不知道這一開始。 (即使兩者的答案是一樣的,我的一些本能仍然希望他們作爲單獨的問題,看起來更清潔,尤其是因爲有關於git和mercurial的單獨答案,哪一個可以接受?) – Cascabel 2010-10-29 17:04:51

回答

5

更改到Mercurial庫被存儲爲一個完整的文件或對先前版本的壓縮增量:

https://www.mercurial-scm.org/wiki/FAQ#FAQ.2BAC8-TechnicalDetails.How_does_Mercurial_store_its_data.3F

水銀使有關是否存儲一個完整的文件與基於增量的決定對所做更改的數量。

這意味着它不只是添加的代碼行,這將增加一個存儲庫的總規模,也:

  1. 對現有代碼進行更改的數量。
  2. 每次提交對每個文件所做的更改次數。
  3. 添加並隨後刪除的文件數量。

Mercurial保留所有刪除的文件。您可以將1GB文件添加到存儲庫,然後將其刪除;行數沒有增加,但由於文件仍然在存儲庫中,存儲庫會相當大。

回答您的問題依次是:

  • 我想象粗略估計X個月後的存儲庫的大小,這是可行的,假設你保持變化以穩定的速度在總庫(即。以相同的速率添加/刪除/更改文件,每次提交的行數大致相同)。

  • 將代碼行數增加10%並不能告訴我們有多少行被刪除/更改,因此增加的代碼行並不一定對應於回購大小的相同增加。

  • 標籤不會影響Mercurial repo大小超過幾個字節。除非你開始研究分支,否則它們會增加與提示相同的開銷。假設發生相同的變化率,提交的數量應與回購規模合理成比例。

  • 提交10倍經常可能不會增加文件大小,因爲它是對回購大小的主要影響的變化率,而不是提交次數。

+0

我認爲最後一點是不正確的。如果您經常提交10倍,那麼增量總和的大小應該大致相同。 – tonfa 2010-10-29 15:20:33

+1

即使存儲完整文件,它們也會壓縮完整文件。這是一個壓縮的增量或壓縮完整,但它總是壓縮。 – 2010-10-29 15:30:31

+0

感謝您的意見。我修改了最後一點。 – Ant 2010-10-29 21:29:24

0

如果你擔心蘑菇大小,去克隆一些在線項目,並檢查其存儲庫的大小。有很多大型項目可以選擇分支機構提交等。我的經驗是git & mercurial,並且保持尺寸不變,尺寸反映了更多的文件,你投入他們(和他們的大小)而不是開銷。

+0

我在Mercurial中創建的存儲庫大約70 Mb,並跨越10000個文件。我只是有點擔心,我們會陷入困境的道路兩三年,但看看與這裏相關的其他項目,看起來我們不會變得更糟。 – MdaG 2010-10-29 22:10:03

3

除非您對提交次數和工作樹的最終大小有一些瞭解,否則直接估計一年的大小顯然是不可能的。

也就是說,git是非常有效的磁盤空間。它絕對不會存儲給定版本的文件的多個副本(這在內部表示爲blob),並且較舊的blob被delta壓縮到包中。這意味着它在存儲純文本方面非常高效,而對於大型二進制文件效率非常低。如果你的項目主要是純文本的,你幾乎肯定沒有什麼可擔心的。

分支和標籤對尺寸基本上沒有影響。當然,一個分支的reflog可能會達到幾KB,但這沒什麼可擔心的。輕量級標籤幾乎只是一個存儲的SHA1,而註釋標籤只是添加了一小部分元數據。

至於代碼行數和提交數量,很難說清楚。通常,提交比代碼行要大得多;你可以有很多版本的文件都加起來(甚至表示爲deltas),但實際內容只需要存儲一次。這是由於工作樹傾向於比.git目錄多得多。例如,我的克隆git.git有一個17MB的工作樹和一個39MB的.git目錄。我檢查的其他項目也有類似的比例。

更多提交的大小相同肯定會使存儲庫增長得更多,但如果將1000個提交併將它們拆分爲10000(包含相同的更改)將不會使存儲庫變得更大。提交對象本身很小;這是文件中的空間差異。你可能會看到一個初始的大小,因爲提交只是週期性的增量壓縮,但一旦被觸發,那些提交就會被壓縮回去。

我能做出最好的概括是,庫的.git目錄將傾向於以速度比例三角洲的每時間量,這在一般的應該是成正比的工作樹的大小和速度增長,在這人們正在修改這個項目。這當然是如此普遍以至於完全沒有幫助,但是在那裏。

如果你想估計,我只是在第一個月左右收集一些數據,然後嘗試擬合一條曲線。

+0

很好的解釋。 – 2010-10-29 15:28:38

+1

聽起來像你需要重新包裝你的git.git。在運行'git gc'後,我的只有36MB。根據我的經驗,具有較小歷史記錄的存儲庫在收集垃圾之後傾向於使用.git dir小於工作樹。 – 2010-10-29 21:51:16

+0

@Kevin:哎呀。我很驚訝,我設法在不觸發'gc --auto'的情況下持續了很長時間。感謝您的支持。 – Cascabel 2010-10-30 05:55:52

1

看看GitBenchmarks頁面上的Git維基,部分「庫大小的基準」和「其他基準和參考文獻」(考慮到基準已經作出,什麼它使用版本),在特別是在最後頁面的條目:

  • DVCS Round-up: One System to Rule Them All? -- Part 3由羅伯特·芬特在Linux開發者網絡,從27-01-2009,包含兩個合成基準測試結果的系統在壓力下的行爲在倉庫提交的(數,或計算的文件數量)。

    測試系統是運行Ubuntu 8.10的虛擬機,軟件版本是SVK 2.0.2(最後是2.2.3),darcs 2.1.0(最後是2.4.4),單調0.42(最後是0.48 ),Bazaar 1.10(最後是2.2.1),Mercurial 1.1.2(最後是1.6.4)和Git 1.6.1(最後是1.7.3)。