How can I create a branch for a non-tip revision in Mercurial?

Question

In my repo, I have the revisions 1 to 10. I've pushed up to 5 (so the next hg push would publish revisions 6-10).

But I have to interrupt my work now and the result isn't 100% complete. So I'd like to move the revisions 6-10 into a new "experimental" branch to allow someone else to complete the work without disrupting the sources for everyone.

How can I add a branch to a non-tip revision (in my case: Starting with revision 6)? Or should I use a completely different approach?

Answer 1

You cannot apply a branch name after the fact without modifying your history.

The most simple approach is to ask the other users to use revision 5 as the parent for any changes they create. For example, the other users would:

1. hg clone <your repo> or even hg clone --rev 5
2. hg update -r 5
3. work, work, work
4. hg commit

When they commit a change, it will create a second head on the default branch, but that should not create any problems. You will simply need to merge the two heads together once your experimental changes are complete.

That being said, moving your changesets onto a branch can be accomplished using Mercurial Queues (MQ). The following sequence shows how it be done:

1. hg qinit (Create a new patch queue)
2. hg qimport --rev 6:10 (import r6-10 into a new patch queue)
3. hg qpop -a (remove all patches from your working copy)
4. hg branch <branch name> (create your new experimental branch)
5. hg qpush -a (apply all the patches to your branch)
6. hg qfinish -a (convert all patches to permanent changesets)

Answer 2

Tim already has good suggestions. Additionally you could push your experimental changes into a distinct experimental clone on your central server (I guess you use one). This clone could also be used by other developers to push their not-yet-finished work in order to let others review or continue it. It is also clear that this clone's code is not ready to be used. Once some task is finished, the corresponding changesets can be pushed to the stable repository.

Actually named branches are a good idea for your case, but the fact that their names are burned into history mostly is more a problem than a feature. IMHO Git's branch names are more practically. However, to some extend you could also handle your case with bookmarks, which are pushable since Mercurial 1.7 (not sure here). That is you bookmark revision 5 with something like stable (or whatever you agree on in your team) and revision 10 gets bookmarked with something like Aarons-not-finished-work. The other developers would then just pull stable, except your colleague who is supposed to continue your work, who would pull the other bookmark. However, personally I did not use a such workflow yet, so I cannot say if it performs well in practice.