Mercurial存储库如何随着时间的推移而增长?

时间:2010-10-29 14:53:57

标签: mercurial dvcs

假设我创建了一个存储库,将 x 文件添加到其中并提交。假设初始提交后大小为 a Mb。

  • 有没有办法估计一年内存储库的大小?

  • 如果代码行增加了10%,那么存储库是否会相应增长?

  • 提交,分支,标签等数量如何影响存储库大小?

  • 同年10000次提交会使存储库增长(显着)超过1000次提交吗?

  • 也许我的问题是错误的措辞?

4 个答案:

答案 0 :(得分:5)

对Mercurial存储库的更改将存储为完整文件或针对先前版本的压缩增量:

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

Mercurial根据所做的更改量决定是否存储完整文件与差异。

这意味着它不只是添加一行代码来增加存储库的总大小,而且还包括:

  1. 对现有代码所做的更改次数。
  2. 每次提交对每个文件所做的更改次数。
  3. 添加并随后删除的文件数。
  4. Mercurial会保留所有已删除的文件。您可以将1GB文件添加到存储库,然后将其删除;行数没有增加,但由于文件保留在存储库中,因此存储库会大得多。

    依次回答你的问题:

    • 我认为在x个月之后大致估计一个存储库的大小是可行的,假设你总是保持对存储库的稳定变化率(即你以相同的速率添加/删除/更改文件) ,每次提交大致改变相同的行数。)

    • 将代码行数增加10%并不能告诉我们删除/更改了多少行,因此代码行的增加不一定与回购协议大小的增加相对应。 / p>

    • 标签不会影响Mercurial repo大小超过少数字节。在您开始研究分支之前,分支也不会分支,此时它们会增加与处理小费相同的开销。假设发生相同的变化率,提交次数应与回购规模成比例。

    • 提交10x通常可能不会增加文件大小,因为它是对repo大小的主要影响的变化率,而不是提交次数。

答案 1 :(得分:3)

直接估算一年中的大小显然是不可能的,除非您对提交的数量和工作树的最终大小有所了解。

那就是说,git非常有效。它绝对不会存储给定版本文件的多个副本(这在内部表示为blob),而较旧的blob会被压缩成包。这意味着它在存储纯文本方面非常有效,而对于大型二进制文件效率非常低。如果您的项目主要是纯文本,那么您几乎肯定无需担心。

分支和标签对大小基本没有影响。当然,分支机构的reflog可能会达到几KB,但这没什么值得担心的。轻量级标签几乎只是一个存储的SHA1,带注释的标签只是添加了一小部分元数据。

至于代码行和提交次数,很难准确说出来。通常,提交是比代码行更大的因素;你可以将许多版本的文件加起来(甚至表示为增量),但实际内容只需要存储一次。这可以通过工作树往往比.git目录更多来支持。例如,我的git.git克隆有一个17MB的工作树和一个39MB的.git目录。我检查的其他项目也有类似的比例。

更多相同大小的提交肯定会使存储库增长更多,但是提交1000次提交并将它们拆分为10000(包含相同的更改)将不会使存储库变得更大。提交对象本身很小;这是占用空间的文件的差异。您可能会看到最初的大小峰值,因为提交只是定期进行增量压缩,但一旦git gc --auto被触发,这些提交将被压缩回来。

我可以做的最好的概括是存储库的.git目录将倾向于以比例的速率增长到每次增量的增量,这通常应该与工作树大小和人们修改项目的速度。这当然是如此普遍,以至于完全没有帮助,但你就是。

如果你想估计一下,我会在第一个月左右拿一些数据,然后尝试拟合曲线。

答案 2 :(得分:1)

查看Git wiki上的GitBenchmarks页面,“存储库大小基准”和“其他基准和参考”部分(考虑基准时的,以及它使用的版本),特别是结束页面的条目:

    Robert Fendt在Linux Developer Network上的
  • {{3},自2009年2月27日起,包含两个综合基准测试结果,测试系统如何在压力下运行(存储库中的提交数量或文件数量) comitted)。

    测试系统是运行Ubuntu 8.10的VM,使用的软件版本是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)。

答案 3 :(得分:0)

如果您担心蘑菇的大小,请去克隆一些在线项目并检查其存储库的大小。有许多大型项目可供选择,分支机构提交等等。我的经验是git&对于保持尺寸缩小而言,这种大小很好,反映了你放入它们的文件(以及它们的大小)而不是开销。