我负责将 SVN 安装从版本 1.5.6 迁移到 1.7.6。作为其中的一部分，我对我们的两个存储库进行了转储/加载循环，并碰巧注意到了一些奇怪的事情..
其中一个存储库“转储”到 2GB 文件，但加载后，它占用了近 23GB 的磁盘空间。这也是 1.5.6 中的一个问题，但我们希望升级可能会有所帮助。
所讨论的存储库有点“奇怪”，因为它包含一个包含 7500 个文件的文件夹(过去最多为 12000 个)和一个包含另外 500 个左右文件的子文件夹，仅此而已。
看起来可能与此问题有关: 350GB SVN repo creates atleast 1MB revision for even a simplest task like branch/tag
我非常不知道我们现在能做些什么，但 repo 协议(protocol)目前正在以可笑的速度增长，如果我们不解决它，我们将需要重新定位它。这是我希望避免的任务。
最佳答案
首先，SVN有两个不同的repository backends :BDB(伯克利数据库)和FSFS(文件系统)。存储库在磁盘上的存在方式取决于此选择，BDB 通常稍大一些。你用哪个？
如果您使用 FSFS，那么您应该阅读 sharding :当您提交更改时，无论多么小，它都会被提交到一个文件中，该文件的最小大小由磁盘设置 - 通常为 2kb -16kb。现在将其乘以提交的文件数量，您可以得到非常大的数字。好消息是您可以运行命令将分片压缩为单个文件:
svnadmin pack /path/to/repository
这可能会大大改善您的磁盘大小。
或者空间问题可能是您提到的每次提交的大量文件问题。
无论如何，您都会问为什么转储文件非常比存储库大小小得多。转储文件是一个单一文件，其格式基本上是存储库上所做的每次提交 - 这是存储库的一种非常简洁的形式(特别是使用 --deltas 时)。由于它被放置在单个文件中，因此避免了分片问题。
我曾经在以前的组织中使用并支持 SVN。最近我转向了 Mercurial DVCS(也称为 Hg，与 Git 类似)。一旦你做出了改变，就很难再想回去了。无论如何，这是来自 Softpedia 的引用关于存储库大小:
Disk space: When the Mozilla project was ported from SVN to Mercurial (very similar to Git in performance), disk space usage went down from 12GB to 420MB, 30 times smaller than the original size. Git is supposed to use the same storage algorithms, so file size should be around the same value.
您可能想调查一下，如果您切换到 Hg 或 Git，会发生什么情况。如果它像 Softpedia 的例子一样引人注目，您可以向您的管理层推荐 Hg/Git。
关于SVN 存储库比转储文件大得多？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/12329313/