Pros & cons: "one big repository" vs "multiple repositories"

[Zingo Andersen]

Greg Ward wrote:
> Hi all --
>
> As I mentioned the other day here, we are planning our big move away
> from CVS, hopefully to Mercurial if I have anything to say about it.
> The big point of contention at the moment is whether we should convert
> our single large CVS repository into a single large Mercurial
> repository (minus stuff that never should have been committed, notably
> historical binary files), or split it up into a reasonable number of
> project-related repositories (probably 8-15).
...
> Other thoughts?  Anyone have experience one way or the other?  Done it
> one way or the other and wish you hadn't?

I have worked in places with "multiple repositories" and "big repository",
(In clearcase in my case) I would always go for a "multiple repositories"
if possible. One really big disadvantage with "big repository" is that the
teams probably must have syncronized releases. Usually we ended up with
situations where you have to put alot of work in stabalize LATEST/trunk/tip
all the time since every one are working LATEST/trunk/tip on all the code
instead of only the part of code that your team need to work on.

If you have "multiple repositories" this problems almost vanish (or atleast
give you less problem) as you have some script/webpage collecting the versions
together to a big project and if something breaks you can usually really
easy just back out the problematic release(es) from the script/webpage without
some strange (D)CVS magic.

In fact the place that did go for a "big repository" are trying to break it
apart but it is going really slow as it is extra work compared to the daily
stuff and as such it is not prioritized by managers. And as usually the "blind"
managers miss the big cost savings it would bring.

-- 
Zingo "Stefan" Andersen   (zingo.org and vectrace.com)