Mercurial with multiple projects

Question

I have a couple of projects with different release cycles sitting in my SVN repository. Releases are created by using the classic tags structure in SVN. When there are bugs to fix in releases a branch is created from a tag, the bug is fixed and then merged from there into trunk.

Now, for multiple reasons, I want to switch from SVN to mercurial with a central push site.

Question: Which is the best way in mercurial to organize multiple projects that share little code between them? Should I create multiple push sites, one for each project?

Please include in the answer a description on how to recreate my release-tag, bugfix branch, ... with your preferred version of repository design.

Edit: I would like to install as little extensions as possible.

Edit2:

Given this SVN layout:

.
|-- project-a
|   |-- branches
|   |   |-- 1.x
|   |   `-- feature-1
|   |-- tags
|   `-- trunk
`-- project-b
    |-- branches
    |-- tags
    |   |-- 1.0
    |   `-- 1.1
    `-- trunk

(thanks @bendin! :) )

Is it better to work with multiple hg push repositories

project_a-trunk
project_a-1.x
project_a-feature-1
project_b-trunk

for the branches. Tags are folded into the appropriate branch.

Or would you rather go with two push repositories in this example

project_a
project_b

with named branches and therefore multiple heads within one repo.

The advantage I see with the multiple heads repos is that I don't have to go hunt for a tag in multiple repos. The disadvantage I see is that the hg book seems to discourage multiple head repos. What would/do you do?

Onassis

+1 I have been struggling with this same issue. One thing I have considered is have single repos for related projects. – Anoa

I wouldn't combine multiple projects in one repo. It makes history messier. Consider mercurial forest extension instead, as dfa suggested. – Squat

Answer 1

Some subversion repositories will group logically unrelated things (i.e. projects with different version numbers and release cycles) under one trunk:

.
|-- branches
|   |-- project-a-1.x
|   `-- project-a-feature-1
|-- tags
|   |-- project-a-1.0
|   |-- project-b-1.0
|   `-- project-b-1.1
`-- trunk
    |-- project-a
    `-- project-b

This kind of layout has no direct analog in mercurial. Each project which has its own release cycle and own version numbers should have its own repository.

Some subversion repositories are structured to do this by giving each project its own trunk, tags and branches:

.
|-- project-a
|   |-- branches
|   |   |-- 1.x
|   |   `-- feature-1
|   |-- tags
|   `-- trunk
`-- project-b
    |-- branches
    |-- tags
    |   |-- 1.0
    |   `-- 1.1
    `-- trunk

You can think of each project as a logical repository within your physical subversion repository. Each project has its own trunk, tags and branches. This also has the benefit that you can keep tag and branch names shorter because you already know which project they belong to.

This layout is also trivial to express with a tool like mercurial. Each "project" becomes a mercurial repository. Tags and branches within that repository are tags and branches of that project.

Squat

Cool. I have the second layout. So what you are saying is that I should create multiple hg repos? – Onassis

Yes. Create one mercurial repository per project. – Squat

This is a good answer to the question of having separate repos for different project, but what about for different releases of the same project? 'the book' seems to suggest different repos for releases, but isn't that a pain for maintaining history, backing up, etc? – Bigamy

Answer 2

Like bendin says, you should create multiple repositories, one for each independent project as a start.

Mercurial commits are made an a repository-wide level and you cannot checkout just a single subdirectory. This is unlike Subversion which allows you to make in-consistent commits by commiting only some files, but then it also allows you to checkout just a single subdirectory.

When you make a release you will typically add a tag to your Mercurial repository (hg tag). You can freely decide if you want to keep a bugfix repository around for each release, of if you want to create them when needed the first time. The trick is that

% hg clone -r 1.0 project-a project-a-1.0.x

can be used to create a repository project-a-1.0.x which only has the history up to the tag 1.0. You can then fix the bug in project-a-1.0.x and push it back to project-a. Further bugfixes can be made in the project-a-1.0.x repository.

Zakarias

Answer 3

I think that you want to try the mercurial forest extension

Richel