How do I update a branch to be the state of a tag on a different branch in Mercurial?

I have a repository with a master and a develop branch.

I want to create a third named branch, say it's called bugfixes.

I want to be able to update to bugfixes and then have the tip of bugfixes be the same as a previous tag on master. (Say that tag is called Release5.1).

I've tried updating to the branch, and then updating to the tag, but that switches the branch back to master (where the tag is). I've also tried merging

hg merge -r Release5.1

but that only brought in the changes and didn't cause the branch开发者_运维知识库 to "go back in time".

How do I get that tag to the the tip of the named branch?

I'm asking this question because my CruiseControl.net guy tells me that we can only do builds off of the tips of branches and not off of specific revisions. (Maybe that is another question....)

---

First some basics:

Merges are directional:

• When you merge bugfixes into master, then master gets the changesets that were committed on the bugfixes branch.
• When you merge master into bugfixes, then the reverse happens.

If you want two branches to mirror each other, then you must do the merge in both directions.

---

I would argue that you don't need the bugfixes branch at all. Instead, I would set a policy that says:

• master should always be in a state that may be released
• Bug fixes are committed to master
• All releases are tags on master
• New features are committed to develop
• When it is time to release, develop is merged into master
• After every release, master is merged into develop to insure that new features are based on the latest release.

This would result in something like this:

---

If you must have a bugfixes branch, then I set a policy like this:

• master should always be in a state that may be released
• All releases are tags on master
• Bug fixes are committed to bugfixes
• New features are committed to develop
• When it is time to for a bug fix release:
  1. Merge bugfixes into master
  2. Tag master
  3. Merge master into bugfixes to make them match
  4. Merge master into develop to make sure new features are based on the latest release.
• When it is time for a major release:
  1. Merge bugfixes into master
  2. Merge develop into master
  3. Tag master
  4. Merge master into bugfixes to make them match
  5. Merge master into develop to make sure new features are based on the latest

This will result in something that looks like this:

---

To fix a bug in an old revision, you should:

hg update <TAG>
hg branch Release1.x
<fix the bug>
hg commit -m "Bug fix to older version"
hg tag Release1.2

...if the bug is present in master, then you should also:
hg update master
hg merge Release1.x
hg commit -m "merged bug fix in Release1.x to master"

This would result in something like this:

NOTE 1: At this point, master has commits which should never be part of a Release1.x release. Due to this, you should never merge master into Release1.x.

NOTE 2: If you must support multiple releases of a product in the field, it is common to have a named branch for each major release. These long-running named branches are then used only for bug fixes. If you are very careful, you can merge bug fixes from one release branch to another, but in my experience it is more common to use hg transplant to copy the changes between branches.

---

I would suggest that you keep the bugfixes branch essentially a mirror of the master branch except for when you are fixing a bug, and once the bug is fixed, merge bugfix back into master to again sync them up.

If you need to maintain multiple old versions of master, you will probably need to have a bugfix named branch for each old version you need to maintain.

Ideally, you wouldn't need a named branch dedicated to bug fixes. Much of Mercurial's power comes from how easy it is to branch from a previous revision (un-named branch). I am not too familiar with CruiseControl.net, but if you can build off of unnamed branches, then all you would have to do is:

1. Update to the tag you want to base the fix on
2. Make the changes
3. Commit (this will make an unnamed branch)
4. Build / test the tip of the new, unnamed branch
5. Tag the new version
6. Merge as needed to make sure all code lines get the bug fix

Due to how Mercurial's internal hash structure works, unwinding changes off of the "stack" (or inserting new changesets into the stack, depending on how you look at it) is a really, really hard thing to do and is likely to break any repositories that were clones of the one you are working on.