Using Mercurial in a Large Organization

Question

I\'ve been using Mercurial for my own personal projects for a while, and I love it. My employer is considering a switch from CVS to SVN, but I\'m wondering whether I should

Answer 1

First of all, some recent discussion on using a DVCS in huge projects is relevant:

Distributed version control for HUGE projects - is it feasible?

One wrinkle with Mercurial is that it seems to be designed around the idea of having a single repository per "project".

Yes, while the norm with Subversion is to have one monolithic repository containing multiple projects, with a DVCS it is preferable to have more granular repositories, with one per component. Subversion has the svn:externals feature to aggregate multiple source trees at checkout time (which has its own logistical and technical issues). Both Mercurial and Git have a similar feature, called subrepos in hg.

The idea with subrepos is you have one repo per component, and a releasable product (comprising multiple reusable components) will simply refer to its dependent repos. When you clone the product repo, it brings along the components it needs.

Should we have one huge Mercurial repository containing everything? If not, how fine-grained should the smaller repositories be? I think people will find it very annoying if they have to pull and push updates from a lot of different places, but they will also find it annoying if they have to pull/push the entire company codebase.

It is certainly possible to have one monolithic repository (and you can even split it up down the track if you need to). The issues with this approach are more likely to come down to release schedles, and how you manage different versions of different components. If you have multiple products with their own release schedules sharing common components, you would probably be better off with a more granular approach, to facilitate configuration management.

One caveat is that the subrepo support is a relatively recent feature, and is not as fully fledged as other features. Specifically, not all hg commands know about subrepos, although the most important ones do.

I suggest you perform a test conversion, and experiment with the subrepo support, organising products and dependent components, etc. I am in the process of doing the same thing, and this seems to be the way to go.