Question

We have our project stored in subversion in following way:

• trunk (main development goes here)
• branches
  • stable (production version of software)
  • internal (old, internal version of software is kept here and only very rarely new code is commited here)

How should I organize my mercurial repostories to host it? I have created three repositories, one for trunk and one for each branch as central servers, but since mercurial has branches, than maybe I am doing it wrong. At least it feels wrong, but when I tried to push single changeset from development local repo to stable local repo it pushed all my new changesets. That’s not what I wanted.

EDIT1

I had revision 623 in trunk and 620 in stable. I wanted to push only changeset 623 to stable. I tried hg push -r623 ../stable, but hg informed me, that 4 changesets were pushed.

Answer 1

Ok, let’s tackle this one question at a time.

Note that for layout and organization, there’s many ways to do this, and the only person to really decide is you.

My advice, however, with the workflow you’ve outlined in your comment, is to use one repository for default and stable, using named branches for the two.

As for the old code, I would keep that in a separate repository, and just merge in whatever you need from the primary one, if you need to do that.

As such, here’s how I would organize it:

• Primary repository
  • default branch (you always have this in Mercurial), this is what you previously called trunk
  • stable branch (this is similar to your stable branch from before)
• Old-code repository
  • default branch, pulled from the primary repository
  • “old” branch, the old code, you can then easily merge from default to old when you need to
    • if you don’t need to merge from default to old, put all the old code in the default branch and don’t create a named branch for the old code

Focusing on the primary repository, this gives you the following abilities:

• You can update back and forth in a single working folder between default and stable
• You can easily diff across branches
• You can easily merge from one branch to another, both ways
• Tags are global, visible all the time

The last question is, how can you cherry-pick changesets when merging.

Well, you can’t. Merging merges the changeset you picked + all its ancestors. That’s how merging does in Mercurial.

There’s two ways to mitigate this:

• transplant extension
• commit the changeset elsewhere to begin with

The transplant extension allows you to take one or more changesets out of one branch, and copy them (transplant them) onto another branch. The changesets will be tagged as transplanted, so future merges will not trip over this. The problem, however, is that other than whatever you add to the commit messages, there’s no visible lines in the graphical log to indicate this is what you did.

The other approach, to commit the changeset elsewhere, is probably best described with an example.

Let’s assume you have the following two branches:

default:  1--2--3--4--5--6
           \
stable:     x--y--z

Now, you want to commit changeset 7 on top of changeset 6 in default, and then “merge” only that changeset, and not 2-5, onto the stable branch, and as I said, merge won’t do that.

What you can do instead is find the previous common ancestor, 1 in this case, commit the new changeset on top of that changeset, in effect getting this repository log:

default:  1--2--3--4--5--6
  |       |\
  +---    | 7
           \
stable:     x--y--z

Then you can merge the 7th changeset onto stable and default:

default:  1--2--3--4--5--6--7
  |       |\               /
  +---    | 7------+------+
           \        \
stable:     x--y--z--7

Here’s how TortoiseHg shows that last repository, I just moved the labels: