当我注意到我的存储库大小以每天 1GB 的速度增加时，这一切就开始了。
我做了一个简单的测试。创建了大小为 35KB 的现有文件夹的分支/标签。我记下修订号并转到$REPO/db/revs/<K-rev>/rev-number/并检查了修订的大小。这是 1 兆字节。听起来很可疑。
关于这里可能出问题的任何想法。我的仓库大小约为 350GB，有约 600,000 个修订。
附：我已经开始重建整个存储库，看看这是否有什么不同，但这可能需要几天的时间才能完成。
发布了同样的问题[电子邮件受保护]并从 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,
/项目/主干/一些非常大的目录，/项目/主干，/项目，
/。重写目录节点时，FSFS始终存储新版本
完整地。 （这与更改文件的方式不同
存储，通常与某些以前版本的差异
相同的文件。）
如果 /project/trunk/some-really-large-directory/ 包含，例如 10000
文件，那么每次提交 blah.txt 都会存储该文件的完整副本
存储库中的目录（及其 10'000 个名称）。
当我开始在版本下保留个人维基时我注意到了这一点
控制在几年前。这是一个包含超过 10,000 条文本的平面目录
文件。我很快注意到提交量相当大。 （我从那时起
由于这个原因和其他原因，切换到 git 来完成该任务。）
也可以看看http://svn.apache.org/repos/asf/subversion/trunk/notes/subversion-design.html#server.fs.struct.bubble-up
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
