当我注意到我的存储库大小以每天 1GB 的速度增长时，这一切都开始了。我做了一个简单的测试。创建现有文件夹的分支/标签，大小为 35KB。我记下了修订号，然后去$REPO/db/revs/<K-rev>/rev-number/检查了修订的大小。它是 1 兆字节。这听起来很可疑。关于这里可能有什么问题的任何想法。我的 repo 大小约为 350GB，大约有 600,000 次修订。
PS 我已经开始重建整个存储库，看看是否有什么不同，但可能需要几天时间才能完成。
2 回答
7
向 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 个名称）。
几年前，当我开始将个人 wiki 置于版本控制之下时，我注意到了这一点。这是一个包含 10,000 多个文本文件的平面目录。我很快注意到提交非常大。（出于这个和其他原因，我已经切换到 git 来完成这项任务。）
于 2010-10-13T14:51:18.767 回答
0
有一个非常简单的解决方案。假设您的存储库包含大量历史标签，您可以将它们移动到/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 个标签的存储库的问题。
于 2018-11-16T13:55:08.923 回答