Advice re. implementing Mercurial

[David Capps]

Hi,

I'm currently investigating Mercurial with a view to moving our company source control system off SVN. I've used Mercurial previously to manage some personal projects, but never anything with a significant number of developers and formal QA process; so, I've read up on the possible workflows and come up with a possible system we could use.

Can anyone offer advice / corrections / criticism about how best to implement HG within our company? Thanks!


Our desired development process (not all of these steps currently happen/work well under SVN!):
-We have a number of developers (mostly adding new features) and support technicians (mostly fixing bugs) committing to source control
-All commits are required to be flagged with a development or support ticket reference, and we also run a lint-alike over the changed files before commit (doesn't prevent commit, just flags up potential issues to be checked)
-Once a developer has completed a change and pushed it out of their private tree, QA are required to test and sign off the new build 
-Once a change has been signed off by QA, that change can go into future releases

My idea for setup:

-Each developer has a private tree
-There is a Development tree on our company server where all changes are pushed to (and pulled from by other developers)
-We'll use the IBugtraqProvider interface in TortoiseHG to enforce linking commits to a particular dev item/ticket, linting the files, and also flagging items up for QA's attention in our internal tracking system (i.e. this item has been pushed to development, please test it)
-Our automated build and test system will just pull from Development and build/run the latest version in the tree
-There is also a Release tree on the company server. Developers don't push directly to this: once QA have signed off a number of changes, a senior developer will pull those changes into Release (rebasing as necessary to avoid pulling in unapproved changes). In an ideal world every change within a given period is signed off, in which case it's easy to just pull all the changes up to a given point; in practice I assume QA may pass a number of changes and reject some others; I think rebase can help us cope with that...?
-In theory Release will always be stable, but in practice we release updates every week or so; so every week, QA will pull a build of the current Release tree and put it through full user acceptance testing, and if it passes, tag/bookmark/(?) that version as one that will be released to our users (and begin the actual release process). If it fails, they'll obviously have to file support tickets, fixes for those tickets will need to be committed and checked in, pulled into Release, and they try again.


Are there any problems with this approach? Ways we could do it better? We haven't yet started migrating off SVN, so if we can do things right (for some value of "right"!) from the start we'd like to do that ;)


Thanks!


David Capps