假设我创建了一个存储库，将 x 文件添加到其中并提交。假设初始提交后大小为 a Mb。
有没有办法估计一年内存储库的大小？
如果代码行增加了10％，那么存储库是否会相应增长？
提交，分支，标签等数量如何影响存储库大小？
同年10000次提交会使存储库增长（显着）超过1000次提交吗？
也许我的问题是错误的措辞？
答案 0 :(得分：5)
对Mercurial存储库的更改将存储为完整文件或针对先前版本的压缩增量：
Mercurial根据所做的更改量决定是否存储完整文件与差异。
这意味着它不只是添加一行代码来增加存储库的总大小，而且还包括：
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页面，“存储库大小基准”和“其他基准和参考”部分（考虑基准时的，以及它使用的版本），特别是结束页面的条目：
{{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＆amp;对于保持尺寸缩小而言，这种大小很好，反映了你放入它们的文件（以及它们的大小）而不是开销。