Subversion 存储库需要多少服务器空间？
我将获得一些任意大小的服务器空间，并获得对其的 ssh 访问权限以设置颠覆存储库。
但是，我不知道要要求多少空间。目前，它将托管我的 cms 项目，以便我的同事也可以为代码做出贡献。但如果它取得进展，我们希望扩展该系统，可能会将许多项目放入回购协议中。
它将包含 php 和其他基于 Web 的代码，以及一些图像。在不过度的情况下，多少空间才算合适？ 20MB？ 200MB？
I'm going to be getting some server space of arbitrary size, and be given ssh access to it to set up a subversion repository.
But, I have no idea how much space to ask for. For now, it's going to host my cms project so that my colleague can contribute to the code as well. But if it gets anywhere, we hope to expand on the system, possibly put many projects into the repo.
It'll contain php and other web-based codes, as well as several images. How much is a good amount of space without overdoing it? 20mb? 200mb?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
考虑到一个需要下载几个图像和 PDF 的典型 Web 项目本身的大小可能为 20MB，如果您想存储 SVN 历史记录，您将需要更多的大小。
例如，在我的个人 SVN 服务器上，对于一个 Web 项目（我的博客，不是那么大），SVN 存储库的大小为 181 MB — 并且不超过 150 个修订版左右（我已经停止在该项目中使用 SVN）。
另一个 （较小：几乎没有像图像这样的二进制文件，框架通过
svn:externals链接） 宠物项目，有大约 100 个修订版本，存储库大小为 49MB。还有一个项目（小网站，只有几次修订，因为我不再维护它，我只是将 SVN 服务器作为备份机制）有一个存储库大小22M；考虑到这个项目，任何较小的东西都会显得很奇怪......
因此，对于一个像样的项目，一天或一天可能需要几百 MB，特别是如果有几个不同的开发人员。
Considering a typical web-project with a couple of images and PDF to download can have a size of 20MB by itself, you'll need more than that if you want to store the SVN history.
For instance, on my personnal SVN server, for a web-project (my blog, which is not that big), the SVN repository has a size of 181 MB -- and there are no more than 150 revisions or so (I've stopped using SVN for that project).
Another (smaller : almost no binary file like images, and the framework is linked via
svn:externals) pet-project with about 100 revisions has a repository size of 49MB.And yet another project (small website, only a couple of revisions, as it's a website I don't maintain anymore, and for which I just SVN my SVN server as a backup mecanism) has a repository size of 22M ; considering the project, anything smaller would seem odd...
So, for a decent project, several hundred MB will probably be necessary one day or another, especially if there are a couple of different developpers.
这取决于项目的规模。显然，您至少需要与项目大小一样多的空间。然后，您将需要更多空间来存储 SVN 跟踪的更改。
如今空间成本高昂，您为什么还要担心过度使用呢？只要投入几场演出就可以了。
It depends on the project size. Obviously, you need at least as much space as the size of your project. You will then need more space for storing the changes that SVN keeps track of.
With the cost of space these days, why are you concerned with over doing it? Just throw a few gigs at it.
获取一个完整修订的大小并将其填写到下一个公式中：
其中 n 是预期的修订数量。 （如果您不知道，请使用 1000 作为 n）
每个分支都应该用相同的公式单独重新计算。
对于每个标签，应保留相同的大小作为一个修订版。
Get the size of one complete revision and fill this in the next formula:
Where n is the expected amount of revisions. (If you have no idea, use 1000 as n)
Every branch should be recalculated seperatly with the same formula.
For every tag should the same size be reserved as one revision.
如果存储库中只有文本，那么它不会变得很大。 Subversion 非常擅长对文本进行增量压缩，并且如果操作正确，则不会使用分支、标签和合并来复制对象。
但是，如果您存储随时间变化的大型二进制文件，尤其是图像或视频等预压缩文件，则存储库将快速增长。另外，如果您签入已编译的可执行文件、Java 类、.NET 程序集，即使只更改了很小的源代码，它们实际上也会有很大差异。 Subversion 仍然尝试对这些文件进行增量压缩，但是它们在各个版本之间在字节级别上发生了很大的变化，因此无法做太多事情。
我们有两个用于大型项目的存储库...尽管有超过 40000 个文件和 20000 个修订版本以及大量分支和合并，但“源”存储库只有几百 MB。它大部分只有文本文件，或者不变的图像。该项目的“构建”存储库大小接近 10 GB，因为我们签入了构建的 Java .class 文件（在某些情况下还签入了整个 JAR 和 EAR 文件）。我们维护“构建”存储库以实现快速部署和回滚（我们不想在紧急情况下从源代码进行构建以回滚到良好版本）。
If all you will be having in the repository is text, it won't get very big. Subversion is very good at delta compression with text, and doesn't duplicate objects with branches, tags, and merges if they are done properly.
However, if you're storing large binaries that change over time, especially pre-compressed files like images or video, the repository will grow rapidly. Also if you check in compiled executables, Java classes, .NET assemblies, which actually vary quite a bit even with only a small source code change. Subversion still tries to do delta compression on these files as well, but they change so much at a byte level from revision to revision it can't do much if anything.
We have two repos for a large project... the "source" repo is only a few hundred MB despite over 40000 files and 20000 revisions with lots of branches and merges. It has only text files for the most part, or unchanging images. The "built" repo for this same project is nearly 10 GB in size, because we check in built Java .class files (and in some cases whole JAR and EAR files). We maintain the "built" repo for fast deployment and rollbacks (we don't want to have to do a build from source to roll back to a good version in an emergency).