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

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了350GB SVN repo创建了至少1MB版本,即使是最简单的任务,如分支/标记相关的知识,希望对你有一定的参考价值。

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

另一答案

有一个非常简单的解决方案。假设您的存储库包含大量历史标记,您可以将它们移动到/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个标记的存储库的问题。

以上是关于350GB SVN repo创建了至少1MB版本,即使是最简单的任务,如分支/标记的主要内容,如果未能解决你的问题,请参考以下文章

centos6.5搭建svn

CentOS6.8下简单快速安装SVN-测试小白的福利

centos7搭建svn服务器

centos安装svn并创建版本库配置用户分组权限

SVN repo损坏了

svn的安装和使用