Question

I’m new with HG, I’m looking for some advice on how to handle this scenario.

We have a central repo hosted at Kiln. The three guys on my team code away and eventually are ready with our code which we tag and release as Version1. We then happily start working on our next major version. While working on it, there’s the need to fix a critical bug in Version1 so James clones his repo using hg clone -r Version1 http://centralrepo where he makes his change and tags it as Version1.1.

Now, how does Version1.1 get back to the central repo? Using hg push causes an abort because there are two remote heads. Without it being in the central repo, Doug can never come along and make a fix to Version1.1 if it ever becomes necessary.

How can I modify my process so that all my tags are always stored on the central repo and easily pulled into the dev branch?

UPDATE/EDIT

With the suggestion from Joel, I made the following tweaks:

On the Kiln website, I create my main active dev repo. Once I have the code in there, I create a new branch from it.

I clone my ActiveDev branch: hg clone http://activeDev code-activeDev
I clone my Stable branch: ht clone http://stable code-stable

I setup a tag on my stable branch: hg tag V1.0 and then push it to the stable branch and to the active dev branch. When going to activeDev I use the -f command. Now both branches are identical.

I do an hg pull and start on a new feature in ActiveDev. Then push that feature back to central:

hg com
hg push

Stable gets a bug fix, then pushed to it’s own repo using the same two commands. Now when I try to push that fix to the activeDev branch, I’m again given the ‘you are making two heads, use -f’ message. However, if I force it, the new feature I pushed earlier in activeDev is blown away by the fixes I did in stable.

Did I do something wrong? Am I missing a step somewhere?

Answer 1

Basically, you need to merge the fix so that there is only 1 head again. There is a way of managing 2 branches that makes doing bugfixes on released versions (in parallel with development) easier:

The process I use is to create a named branch called Stable in addition to the default branch. I work on new features and whatnot on the default branch. Whenever I do an actual release of code, I merge that over to the Stable branch and only tag things like v1.0, v1.1, etc. on that branch.

Then I can continue development on the default branch, but when a bug comes up that is relevant to a previous version I can put that fix on the Stable branch and recompile. When ready, I merge fixes from the Stable branch over to default to make sure that Stable is always just a subset of default.

If you start using this, the first time you push that named branch to central you will have to use hg push --force, but only once.