Recommended Mercurial repository/folder structure for an SVN user

Question

I am experimenting with Hg with a view to moving away from SVN but wanted some opinions on how I should structure my Hg repository. I come from a SVN background (which may of tainted my outlook on how this should work!) and my repository currently looks something like this:

Project1   trunk   branches     1.0     1.1 Project2   trunk 

etc. This seems to be the 'traditional' way to structure an SVN repository.

How should I reproduce this with Hg? To spice this up a little I like the idea of 'stable', 'qa' and 'dev' repositories/folders and would like to introduce this if possible.

I am an Hg beginner so any help or advice is welcome.

Answer 1

There are several structural differences between a Subversion (SVN) and Mercurial (HG) repository, or repo for short, implies how you'll "design" your hierarchy:

• Mercurial works better with only one project per repository: Because you always have to clone the entire repository, having multiple project in a single repository might have a big impact on the cloning time as well as on the pushing/pulling operations, as you'll have to synchronize all the job that was done on other projects than yours each time.
• SVN does not have a "strong" notion of tagging/branching, while Mercurial does: In SVN (at the time of writing), each branch, each tag, is basically a copy of a given project/folder/whatever. The recommended trunk/branches/tags structure is there to help you to find your "copies" back, no more. On the other side, branches and tags are well defined in mercurial. A tag is really a name that you put on a particular revision, and you can ask for all the existing tags. For branches, you'll see that there are MANY ways to handle them, but the one that fits best to the SVN philosophy, are named branches.

With that in mind, and coupling it with you idea of stable, quality assurance (QA), and development (dev) process, here is what I would recommend:

• One repository named "Stable" per project. Several "QA" repos per project and tons of "Dev" per project.
• Tags and names branches are only defined by the "Stable" repo, or eventually by the "QA". The "Dev" repos can handle them differently without hurting.
• You never make a push to a "QA" or "Stable" repo, they pull, or they integrate bundles or patches, and there's one person responsible for each.

Example: MyProject-1.0

 [STABLE Repository, pulls from any/all QA]   - MyProject-1.0   [QA Repositories, branched from STABLE, pulls from any/all DEV ]   - QA_MyProject-001 (Person A)   - QA_MyProject-002 (Person B)   - QA_MyProject-003 (Person C)             ...   - QA_MyProject-### (Person #)   [DEV Repositories, branched from STABLE or QA]   - DEV_MyProject-001 (Feature X)    - DEV_MyProject-002 (Feature Y)   - DEV_MyProject-003 (Feature Z)             ...   - DEV_MyProject-### (Feature #)    1. DEV completes feature(s)   2. QA pulls feature(s) from DEV   3. STABLE pulls from all approved QA(s) (consolidating all changes)