即使是最简单的任务(如分支/标记),350GB SVN repo也会创建至少1MB的版本

F Y*_*oob 6 svn size repository fsfs

这一切都始于我注意到我的存储库大小以每日1GB的速度增加.我做了一个简单的测试.创建了大小为35KB的现有文件夹的分支/标记.我记下了修订号,然后去了$REPO/db/revs/<K-rev>/rev-number/并检查了修改的大小.这是1兆字节.这听起来很可疑.关于这里可能出错的任何想法.我的回购大小约为350GB,大约有600,000个版本.

PS我已经开始重建整个存储库,看看是否有任何不同,但可能需要数天才能完成.

F Y*_*oob 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/contains,比方说10000个文件,那么每次提交到blah.txt都会在你的存储库中存储这个目录的完整副本(有10'000个名字).

几年前,当我开始在版本控制下保持个人wiki时,我注意到了这一点.这是一个超过10,000个文本文件的平面目录.我很快发现提交很大.(由于这个原因和其他原因,我已经为了那个任务而改用git.)

另见 http://svn.apache.org/repos/asf/subversion/trunk/notes/subversion-design.html#server.fs.struct.bubble-up