当我注意到我的存储库大小以每天 1GB 的速度增加时，这一切都开始了。
我做了一个简单的测试。创建了一个大小为 35KB 的现有文件夹的分支/标签。我记下修订号并转到 $REPO/db/revs/<K-rev>/rev-number/并检查了修订版的大小。它是 1 兆字节。这听起来很可疑。
关于这里可能有什么问题的任何想法。我的 repo 大小约为 350GB，大约有 600,000 次修订。
附言我已经开始重建整个存储库，看看这是否有什么不同，但可能需要几天时间才能完成。
最佳答案
向 users@subversion.sapache.org 发布了同样的问题，并从 B Smith-Mannschott 那里得到了这个答案 - 这解释了一切。我确实在包含 16000 个文件夹的路径中有一个目录 - 对于每次提交。感谢 B Smith-Mannschott 的详细回复。为了他人的利益，在此处发布回复。
您的存储库是否包含一个包含很多条目的目录？是
产生大量提交的更改正在或低于此类
目录？
让我们假设将对单个文件的单个更改提交到您的
存储库。让我们进一步假设该文件位于此处，在您的
存储库:
/project/trunk/some-really-large-directory/notes/blah.txt
当您提交对 blah.txt 的更改时，新修订将重写
'blah.txt' 和存储库根目录之间的目录节点:
/project/trunk/some-really-large-directory/notes,
/project/trunk/some-really-large-directory,/project/trunk,/project,
/.重写目录节点时，FSFS 总是存储新版本
整体而言。 (这与更改文件的方式不同
存储，通常作为与某些以前版本的差异
同一个文件。)
如果/project/trunk/some-really-large-directory/包含，比如说 10000
文件，然后每次提交到 blah.txt 将存储此文件的完整副本
存储库中的目录(包含 10'000 个名称)。
当我开始在 version 下保留个人 wiki 时，我注意到了这一点
几年前控制。这是一个包含 10'000 多个文本的平面目录
文件。我很快注意到提交非常大。 (我从
出于这个原因和其他原因，为该任务切换到 git。)
也可以看看
http://svn.apache.org/repos/asf/subversion/trunk/notes/subversion-design.html#server.fs.struct.bubble-up
关于svn - 350GB SVN repo 为即使是最简单的任务(如分支/标记)创建至少 1MB 的修订版，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3910387/