Branch-per-feature workflow using Mercurial

Question

We have team of 10 developers who works parallel for different features, sometimes these features use common code sometime no. And now we're changing our process to branch-per-feature and it seems mercurial is more suitable for such development.

I see this process so: 1. make release branch (rb) from default(trunk) 2. make feature branch (fb) from default(trunk)

When developer thinks his feature is done he can merge fb to rb. When it's time to go to QA we merge all finished fb to rb and create release for our QAs.

Questions:

1. When QA finds a bug developer should modify his fb and merge it again to rb. Does it mean that developer just switch to his fb and start fixing the bug and then makes simple merge fb to rb again?

2. When release is passed QA it goes to PROD - how can we freeze changes? "hg tag" is good choice but someone can update tag if he really wants it.

Thanks

Answer 1

If you're going to merging into specific release branches then your feature branches should be branched from the release branch, not the trunk. It is simpler to merge with the parent branch than a non-parent branch.

1) If you really want to do feature branches then each bug would have its own branch. This will help keep bug fixes separate from new features. After all, it's branch-per-feature not branch-per-developer.

2) Hg tag is what I have used. You are right that someone change move a tag if they really want to, but tags are versioned and you can install hooks on the main hg repo to throw alerts if a tag is moved. I really wouldn't worry about tags being moved unless you can't trust your developers, in which case you are screwed.

Answer 2

The answer to your first question is 'yes'.

The best way to freeze for release is to have a separate release clone that only the release manager can push/pull changesets to. Just because you're using branches doesn't mean multiple-clones don't have a place in your workflow. Have a clone that QA does final pre-flight testing on to which developers can't push changes makes for a great firewall.

Also, consider using bookmarks for your feature branches. Since, as I'm sure you know, Mercurial named branch names never go away the git-like bookmarks work well for sort lived concepts like features and bugs.