CODEWITHSUNDEEP
version-controlmercurial
Max Grigoriev
Max Grigoriev

Reputation: 1031

Branch-per-feature workflow using Mercurial

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 (r-b) from default(trunk) 2. make feature branch (f-b) from default(trunk)

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

Questions:

  1. When QA finds a bug developer should modify his f-b and merge it again to r-b. Does it mean that developer just switch to his f-b and start fixing the bug and then makes simple merge f-b to r-b 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

Upvotes: 4

Views: 1014

Answers (2)

Ry4an Brase
Ry4an Brase

Reputation: 78330

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.

Upvotes: 2

Mark Robinson
Mark Robinson

Reputation: 3145

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.

Upvotes: 3

Related Questions