我已经负责将我们的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
我现在对此我们能做些什么感到非常茫然，但回购目前正在以一种嘲讽的速度增长，如果我们不解决它，我们将需要重新安置它。我希望避免的任务。
答案 0 :(得分：1)
首先，SVN有两个不同的repository backends：BDB（Berkley DB）和FSFS（文件系统）。存储库在磁盘上的存储方式取决于此选择，BDB通常要大一些。你用哪个？
如果您使用FSFS，那么您应该阅读sharding：当您提交更改（无论多小）时，它将被提交到最小大小由磁盘设置的文件中 - 通常为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。