From: James Oltmans [mailto:firstname.lastname@example.org]
Sent: Thursday, April 05, 2007 5:00 PM
To: Andrew R Feller; email@example.com
Subject: RE: Pros and cons of significantly large repositories
Using multiple repositories for code that you may want to merge together is
a bad use of multiple repositories. I do not recommend it. Separating your
documentation from your source code would be a fine separation but the
documents aren't likely to take up a lot of space and the separation might
make it harder to find.
I agree with James above. I like to keep everything that is related to a
project or product in one repository. That means that by checking out a
particular revision of the repository, I can get everything related to the
project as it stood at that point in time. If one project messes up its
repo, then other projects are unaffected.
The more repos you have, the more complicated your setup of permissions,
hook scripts, and whatnot will be. So there's another tradeoff.
The consultant that got us started on the Subversion road recommended
storing the binary builds in the same repository. I personally believe
This depends on your build. One of our tools embeds a date code into the
binary, and our user cares about it. So archiving the "golden build" is
necessary in this case. If you trust your tools enough to faithfully
reproduce a build, you don't have to store build products. Another "binary"
we archive are installers. We can always re-create an installation program,
but we find it very convenient to avoid doing that. We consume a lot of
disk space, but it has been manageable. The benefits of having everything
controlled have outweighed the costs of a big repository.
that if your binaries are quite large it would be a better idea to just
back them up somewhere else like some other repository or just on disk (if
they go poof you should be able to rebuild them right?). There are pros
and cons to each side of the argument, but my advice would be to pay
One nice thing about storing binary builds is that SVN makes it easy to
demonstrate that a file is bit-for-bit correct and makes it easy to track
changes. That helps me to show that a particular "golden file" really has
not changed since it was created.
attention to how big the binary is and realize that the binary will
increase the size of the repository by the size of the binary if you are
them into separate labeled release folders. Unless you are loading them all
into the same folder/location, you will not get the benefits of the binary
There's my two cents, hope it helps.
Good points, James. Here's another 40% of a nickel. Erik
From: Andrew R Feller [mailto:firstname.lastname@example.org]
Sent: Thursday, April 05, 2007 12:52 PM
Subject: Pros and cons of significantly large repositories
My company is currently trying to use Subversion not only to store code for
new projects but also dumping of binary builds and internal documentation
(processes, meetings, etc). The question most often asked is "Are you going
to use a single repository or multiple repositories?" I know a Subversion
repository can hold any amount of data, but I want to know is:
What are the pros and cons for having really large repositories versus
multiple, smaller repositories?
What experiences have people had with repository administration and general
usage that have made a particular choice good or bad?
I appreciate your feedback and insight!
Received on Thu Apr 5 23:53:57 2007