Subversion存储库需要多少服务器空间?

考虑到一个典型的包含几个图片和要下载的pdf的Web项目本身可以有20MB的大小,如果您想要存储SVN历史,那么您需要的就不止这些。

例如,在我的个人SVN服务器上,对于一个Web项目 (我的博客,没那么大) ,SVN存储库的大小为181 MB——修订不超过150次左右。 (我已经停止在那个项目中使用SVN) .

另一 (更小:几乎没有类似图像的二进制文件,框架通过 svn:externals ) 大约100个版本的PET项目的存储库大小为49MB。

还有另一个项目 (小网站,只有几个版本,因为它是一个我不再维护的网站,我只是把我的SVN服务器作为备份机制) 仓库的大小为22m;考虑到这个项目,任何较小的东西都会显得很奇怪…

因此,对于一个体面的项目,数百MB可能在某天或某天是必需的,特别是如果有几个不同的开发人员。

这取决于项目规模。显然,您至少需要与项目大小相同的空间。然后,您将需要更多的空间来存储SVN跟踪的更改。

由于这些天的空间成本,你为什么担心做得过火?就朝它扔几个球吧。

获取一个完整版本的大小,并将其填入下一个公式:

TotalSize = OneRevisionSize * (n * 1.09)

其中n是预期的修订量。(如果你不知道,用1000作为n) 每个分支都应该使用相同的公式分别重新计算。 对于每个标签,应保留与一个版本相同的大小。

如果存储库中的所有内容都是文本,那么它不会变得很大。Subversion非常擅长对文本进行增量压缩,如果操作得当,它不会复制带有分支、标记和合并的对象。

但是,如果您存储的大型二进制文件随时间变化,特别是图像或视频等预压缩文件,存储库将迅速增长。同样,如果你检查编译的可执行文件,Java类,.NET程序集,即使只有一个小的源代码更改,它们也会有很大的变化。Subversion仍然试图对这些文件进行增量压缩,但是它们在字节级别上从修订版到修订版的变化太大了,如果有的话,它也做不了什么。

我们有两个大型项目的回购…尽管有超过40000个文件和20000个修订版,并且有许多分支和合并,但是“源”回购只有几百MB。大多数情况下,它只有文本文件或不变的图像。这个项目的“内置”回购协议的大小接近10 GB,因为我们检查了内置的Java.class文件(以及在某些情况下,整个JAR和EAR文件)。我们维护“构建的”repo,以便快速部署和回滚(我们不想在紧急情况下从源代码进行构建,从而回滚到好的版本)。