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

Mercurial is really well documented. You only have to know where to look in the Wiki.

You can look at Mercurial's wiki article RepositoryNaming to find some of your answers.

You should also read the official Mercurial manual: Mercurial: The Definitive Guide

Good luck!

Answer 2

But before you do that - check this out: hginit.com - it's a ½ hour read, and it has a section for svn-users.

Made me a lot wiser, and I decided on abandoning /trunk /tag structure, and use mercurial in a different manner. I now have a repository for every project, that just contains the structure of the project, and i tag using the mercurial tag command.

.Jesper Hauge

Answer 3

There are several structural differences between SVN and HG that implies how you'll "design" your herarchy:

• Mercurial works better with only one project per repository: Because you always have to clone the entire reposiory, having multiple project in a single repository might have a bug 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/wathever. The recommended trunk/branches/tags structure is ther 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 sable/qa/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.