views:

216

answers:

3

I work for a web development company that uses Mercurial as its DVCS of choice. We're currently in the process of creating a new version of a site that is already in production.

Both a stable and a development branch of the site exist in the same repository. The production site runs off the stable branch, and developers obviously code against the development (dev from now on) branch (apart from bugfixes).

This model is quite new to us. After the last major production push, we created the development branch from the just-released stable branch (using hg branch dev from the latest stable revision and committing to create a new tip).

A significant amount of new code exists in the dev branch now that we're nearing another release. Meanwhile, the stable branch has only seen bugfixes, all that have been ported over to the dev branch already.

When we're satisfied with the state of the dev branch and deem it production-ready, what we'd like is for the then-current state of the dev branch to become the new stable branch. In one swift stroke, the stable branch would assimilate the tons of changes that have been made to the dev branch. The dev branch would (we assume) essentially become inactive, until such a time that we start developing new stuff again.

What is the correct process for actually achieving this? A simple merge from the tip of dev while having the tip of the stable branch checked out, or something else? As I said, all changes to stable already exist in dev, so we're okay with dev just becoming stable as-is.

And once the mystical transmogrification of dev into stable has been done and the result has been tagged, what's the process of beginning further development on the dev branch again, since after a merge into stable it won't have an active tip to check out? Just check out the last dev revision prior to the merge and commit on top of that to create the new tip? That seems wrong; my gut instinct tells me that the "new dev" should be spun off of the merged & tagged tip of the stable branch, but I don't know how that's done. (As said, last time we did this by creating the named dev branch in the first place; this time we just want to create a new tip to the existing, though probably inactive-post-merge dev branch)

Simple questions to anyone who is more accustomed to distributed version control and Mercurial, but it's not too long since we left SVN-land and things are still a bit hazy. Any help is appreciated.

+1  A: 

Not a direct answer to your question but an excellent tutorial on mercurial exists here. This tutorial explains merging in a very simple way. I have found that I understood Mercurial better after reading this than any other book.

Vincent Ramdhanie
+2  A: 

I would:

  • first rebase dev on top of stable: see Mercurial rebase
    That will allow you to solve in the dev branch any last conflicts which may occurs with the bug-fixes made on stable branch during the dev branch lifetime.
  • then merge stable in dev (trivial merge): stable now contains all its bugfixes and dev changesets.
  • create a new dev (dev2) branch from there, since the old one just got its history rewritten, which is not nice for anyone pulling from it. It is better to agree (for the developers) to pull from a new one.
VonC
+3  A: 

If the development branch has all additions you've made to your stable branch, and the development branch is ready to be the new stable branch, you could just branch a new stable branch of the development branch. The old stable branch could be kept around as is in case users of the legacy code need a hotfix.

Frank Schwieterman
After discussing the options with co-workers, we found this to be the best solution for our needs. Our next stable branch would be e.g. "stable_april_2010", spawned off dev and taken to production. After the development cycle on the dev branch, we'd create "stable_may_2010" from the state of dev at the time and update production to run on that, and so on.We discovered there's an option for closing a branch with hg commit --close-branch, which leaves the branch intact but hides it from view. This will be useful for preventing obsolete stable branches from cluttering branch listings.
JK Laiho
This is the same approach my company took, instead of the usual multiple-clone way (one for each release), because it's easier to manage when you have all your releases in the same repo with consistent names, and it's easier to centralize pulling (we don't allow developer push, instead we have an "integrator" pull from developer clones).
Geoffrey Zheng