这一切都始于我注意到我的存储库大小以每日1GB的速度增加。我做了一个简单的测试。创建了大小为35KB的现有文件夹的分支/标记。我记下了修订号，然后去了$REPO/db/revs/<K-rev>/rev-number/并检查了修订版的大小。这是1兆字节。这听起来很可疑。关于这里可能出错的任何想法。我的回购大小约为350GB，大约有600,000个版本。
附：我已经开始重建整个存储库，看看是否有任何区别，但可能需要数天才能完成。
将相同的问题发布到[email protected]并得到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 / contains，比方说10000个文件，那么每次提交到blah.txt都会在你的存储库中存储这个目录的完整副本（有10'000个名字）。
几年前，当我开始在版本控制下保持个人wiki时，我注意到了这一点。这是一个超过10,000个文本文件的平面目录。我很快发现提交很大。 （由于这个原因和其他原因，我已经为了那个任务而改用git。）
有一个非常简单的解决方案。假设您的存储库包含大量历史标记，您可以将它们移动到/tags-archive并使此目录为只读。当您在/tags下创建新标签时，将不再出现问题。
请注意，您需要使用URL移动URL。例如。
svn move https://svn.example.com/MyRepo/tags https://svn.example.com/MyRepo/tags-archive -m "Your Log Message"
此解决方案有助于解决在一个目录中包含大约350,000个标记的存储库的问题。