views:

148

answers:

0

This is a cousin question with my earlier question of "How to manage concurrent development with mercurial", which covers individual developer workflow. The answer to this question will actually influence the choice for developer workflow.

This is NOT a general "release management best practice" or CI question, as it has been asked many times with good answers, and there's a huge body of literature available to kill time.

I'm only asking for specific ways to use mercurial within the context of release management.

The most obvious and predominant answer would supposedly be stable/default, which is thoroughly covered by the beautiful blog of @Steve Losh, and more concisely in an answer from him. It's simple and effective.

A prominent example of this setup is hg itself. hg uses a few more repositories for active development, but for release management purposes everything seems to be contained in the stable/default branches of the main repo.

The hg setup actually manifests a variation, or rather an extended version, of stable/default: branch clone. I described the process in an answer to a question on named branch vs. multiple repos (with a great answer from @Martin Geisler). What I forgot to mention in my answer is how branch clone works for developer workflow: if you need to fix a bug for a branch, you would hg clone <main repo>#<branch> but not the branch clone, because your changeset will still go back to the main repo and pushed out to branch clone automatically. Of course you can choose not to clone and just hg update <branch> in your main clone, but most arguments for using separate clones (especially the independent build) apply here.

Now back to the question: Are there any other ways that fit different real-world scenarios? For example, a traditional major/minor/patch release cycle with long lapse between releases probably require quite a different workflow than a fast-paced, release-as-you-go web application. Please also comment on the stable/default and branch clone approaches if you feel like.

Since this is almost a survey question, I can only try to accept the "best" answer subjectively. If I can get a few more answers than my developer workflow question, that is.

Thank you for all your inputs!