我负责将我们的 SVN 安装从版本 1.5.6 迁移到 1.7.6。作为其中的一部分，我对我们的两个存储库进行了转储/加载循环，并且碰巧注意到了一些奇怪的事情。
其中一个存储库“转储”到 2GB 文件，但在加载后，它占用了近 23GB 的磁盘空间。这也是 1.5.6 中的一个问题，但我们希望升级可能会对此有所帮助。
有问题的 repo 有点“奇怪”，因为它包含一个包含 7500 个文件（过去最多 12000 个）的文件夹和一个包含另外 500 个左右文件的子文件夹，就是这样。
看起来它可能与这个问题有关： 350GB SVN 存储库为分支/标签等最简单的任务创建了至少 1MB 的修订版
我对我们现在能做些什么感到非常茫然，但是回购目前正在以可笑的速度增长，如果我们不能解决它，我们将需要重新定位它。我希望避免的任务。
首先，SVN 有两个不同的存储库后端：BDB（Berkley DB）和 FSFS（文件系统）。存储库在磁盘上的存在方式取决于此选择，BDB 通常会更大一些。你用哪个？
如果您使用 FSFS，那么您应该阅读分片：当您提交更改时，无论多么小，它都会被提交到一个由磁盘设置的最小大小的文件中 - 通常为 2kb -16kb。现在将它乘以提交的文件数，你可以得到非常大的数字。好消息是您可以运行命令将分片压缩为单个文件：
svnadmin pack /path/to/repository
这可能会大大提高您的磁盘大小。
或者空间问题可能是您提到的每次提交的大量文件问题。
无论如何，您会问为什么转储文件比存储库的大小要小得多。转储文件是单个文件，其格式基本上是对存储库所做的每次提交 - 这是存储库的一种非常简洁的形式（尤其是在使用 --deltas 时）。由于这被放置在单个文件中，因此避免了分片的问题。
我曾经在以前的组织中使用并支持 SVN。最近，我将自己转移到 Mercurial DVCS（也称为 Hg，类似于 Git）。一旦你做出了改变，就很难再想回去了。无论如何，这里是来自Softpedia关于存储库大小的引用：
磁盘空间：当 Mozilla 项目从 SVN 移植到 Mercurial 时（性能非常类似于 Git），磁盘空间使用量从 12GB 下降到 420MB，比原始大小小 30 倍。Git 应该使用相同的存储算法，因此文件大小应该是相同的值。
如果您切换到 Hg 或 Git，您可能想调查一下您的情况会发生什么。如果它与 Softpedia 的示例一样引人注目，您可以向您的管理层推荐 Hg/Git。