how much server space do I need for a subversion repository?

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?

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.

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.

Get the size of one complete revision and fill this in the next formula:

TotalSize = OneRevisionSize * (n * 1.09)

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.

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).