How do you associate a named branch with a different changeset in Mercurial?

Question

I converted a repository from Git to Mercurial, and created a named branch production for our production development. Unfortunately, a week later, we've just realized the production branch is on the wrong changeset.

Although we've made a number of changes to the repository, there haven't been any commits to the production branch yet. I need to somehow reassociate the production name with the correct changeset, or delete the branch and recreate it.

What's the best way of doing this?

Answer 1

If there have been no "commits to the production branch yet" then the branch doesn't yet exist. In mercurial's named branches a branch name is an indelible label on a committed changeset. A changeset never changes what branch it's on. I'm going to assume you've got at least one changeset with the production branch label or this turns into a no-problem question.

If you take these actions I think you'll end up okay:

1. hg update to the revision you wish was the production head
2. hg branch production this just says the next commit should have the production label
3. hg commit you'll now have a new commit with the label production

Now when people do a clone of just production:

hg clone repopath#production

or

hg clone -r production repopath

or update to it

hg update production

They'll get the branch of development you want. That old changeset(s) will still (and always will) have the production label, but that's likely okay. If it's really not okay you could rebuild the repo and remove the labels from those commits, but the process above gets people cloning/updating production the right stuff, so you should be fine.

Answer 2

You can do it, very easily, by using the mq extension. Obviously, this requires everyone to get a new clone of the repository.

If the production branch was created in changeset 869, and you wanted it on changeset 842, you can say:

hg strip 869
hg update 842
hg branch production

This will remove changeset 869 (and all its descendants) from the repository, renumbering any subsequent changesets to fill in the gaps, and then assign the production name to the correct changeset.