Advice re. implementing Mercurial

[BOGGESS Rod CORE]

Tenova: advanced technologies for the metals and mining industries
Visit our website at www.tenova.com
------------------------------------------------------------------
Confidentiality Notice : This message, together with its attachments, contains strictly confidential information and is intended only for the addressee identified above,who is the sole party authorized to use
 and copy it and, assuming any related liability , to forward it to others. Anyone receiving this message by mistake or reading it without authorization is hereby notified that storage, reproduction, disclosure or distribution of the message to persons other than the addressee is strictly forbidden. They are asked to return the message immediately to the sender and to erase the original message received.
Thank you.


-----Original Message-----
Subject: Advice re. implementing Mercurial

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 ;)

                                -:-:-:-:-:-:-:-:-:-:-:-:-

This isn't significantly different from what we do. We don't have an issue tracker yet. (I've been looking at that the past couple of days.) Some offer better integration with Hg than others, if that's a desired attribute. Supposedly, synching on Windows Shares is problematic, and a web host is recommended (for the central, canonical repo), but the only problems we've had are abandoned locks, and they're relatively easy to fix with our small group.

You might want to look at evolution or MQ, as an alternative to rebase. I've always been a fan of planting a seed, giving it some help getting started, then getting out of the way and watching what grows, trimming a little here and there along the way. (No battle plan ever survives the first five minutes of battle, yet the battle plan can be the most decisive factor in determining the outcome of the battle.)

It sounds like you’re on the right track.