Mercurial hg, am I doing it right?

Question

We are in the process of converting from CVS to Mercurial hg.

Our infrastructure is Windows 2003/IIS6

• Each developer develop on their machine
• 1xDevelopement server
• 1xStaging server
• Production environment

Here's what I have done so far:

Installed Mercurial on my machine, on the development server and on the staging server.

1. Created a repository on the dev. server.
2. Imported our CVS repository in there.
3. Cloned that repository to my local machine.
4. Cloned that repository to our staging server.

For development in the past we always shared 1 branch, not ideal but merging was such a pain that we never bothered and dealt with it.

Now if I understand correctly, we should be doing this:

Local:

1. hg branch myfeature1 //Start work on feature1

Urgent bugfix required, using the affecting the SAME files as our feature

2. hg update default
3. hg branch bugfix1 //fix bug
4. hg commit --rev bugfix1 //done fixing bug we commit
5. hg push --rev bugfix1 -f //-f seems odd here, forcing to create a new branch
6. hg update feature1 //we return to work on feature1
7. hg commit --rev feature1 //done work commit
8. hg push --rev feature1

DEV

1. hg branches //we see the bugfix and feature1
2. hg merge --rev bugfix1
3. hg commit //commiting bugfix1
4. hg merge --rev feature1
5. hg commit //commiting feature1 //Dev master is now our main trunk ready for a new developer containing the feature1 and bugfix1.

Staging (The QA needs to signoff on that important bugfix before testing feature1

1. hg incoming //we see the new stuff
2. hg pull --rev bugfix1
3. hg merge --rev bugfix1
4. hg commit
5. //QA test and signoff bugfix1 we clone to a production repo and sync.
6. //QA can now test feature1 which we finished some days after bugfix1
7. hg pull --rev feature1
8. hg merge --rev feature1
9. hg commit //commiting merge feature1
10. //QA test feature1 and signoff
11. We clone to a production repo and sync.

Does this way make sense? Am I complicating things and will it bite me in the ass later?

Answer 1

It looks like you've got the concepts down great, but you've got some oddities and some questions in there, I'll hit them as a list below:

1. commit doesn't take a --rev option. It commits the current working directory as a new changeset whose parent (or parents if it's a merge) is whatever hg parents returns, which is always whatever you last hg updateed to.
2. your hg push --rev bugfix1 -f won't require a -f in very new (1.5+) versions of mercurial. Historically the warning "you're creating a new head" usually meant you forgot to merge, but now if the new head is a new named branch the warning is suppressed.
3. If I were your person doing the emergency bug fix on my local machine I'd just create a new clone and do the branch and fix in there. If you set up your webserver/webapp config to support that you can allow new instances at new path locations easily/automatically
4. In your staging environment, I recognize the desire to have them test the bugfix independent of the feature and that's a good idea, your QA team shouldn't be merging. Make/let the developers merge and have the QA team pull the merge revisions into their working area. For example, the developer changeset created in DEV step 3 already provides the proper integration of the bugfix and what-used-to-be, so have the QA team pull that revision, which will be on the 'default' branch. Similarly, after QA has approved the bugfix and is ready to move on to the feature, have them pull from dev the changeset created in dev step 5.

Remember, merging is coding too -- the person doing the merge is making choices about what should and shouldn't be. The QA people might be capable of it, but it's the developer's job. Also, why do it twice? The usual handoff for this is something like "QA, pull revision 897a9d9f9a7 and test please -- the developers". If you want to get fancy you can have a tag like 'readyforQA' that the developers move along the 'default' branch as they go (in this example they'd hg tag after their steps 3 and 5 and let QA know there's new stuff to pull.

The one piece of advice I'd give you is don't try to over-engineer the process. DVCSs lead to a sort-of haphazard way of working, that's a little scary at first, but tends to work out. YOu'll find sub-teams and pairs of folks have clones you never knew about and in the end so long as you have a few firm rules like "nothing goes to production without first passing through QA" the rest sort of works itself out.