managing multi-version development with mercurial

[Greg Ward]

On Mon, Nov 30, 2009 at 5:14 PM, Mike Jarmy <mjarmy at gmail.com> wrote:
> At my day job, I'm doing the groundwork for recommending that we
> switch to a DVCS from a proprietary centralized VCS.  I work on a very
> large project (many thousands of files) that has been around for many
> years, and has had several different  releases.  I've been looking in
> to both git and hg as replacements, and while I think I understand how
> we would set things up if we switch to git, I'm still unsure what our
> setup would look like in hg.

That sounds like me 6 months ago, except read "CVS" rather than
"proprietary centralized VCS".  We've got ~10 years of history, ~25
developers currently, ~21,000 files on CVS trunk, ~104,000 commits,
~30 historical release branches, ~100 historical development branches.
 It's a good-sized project.

> For the sake of argument, lets say that the releases are called v1,
> v2, etc.  In the past, once we released a new version, say v4, then v3
> would essentially get mothballed except for bugfixes.

[in the voice of Michael Palin playing the old guy stuck in prison for
20 years in *Monty Python's Life of Brian*]
"Mothballed release branches?!  You lucky bastard!  O, how I *dream*
of the day where we can retire old release branches..."  ;-)

Just the other day, I merged several changes across 11 release
branches in Mercurial as a test.  Then I had to go do it again in CVS,
because that was only my weekly throwaway "test the new workflow"
Mercurial repo.

> Any changes to
> v3 would also need to be added to v4.

Advice #1: don't think transplant (or cherrypick).  Think merge.
Merging should be the preferred course of action most of the time.
Transplant is for the exceptional circumstance, e.g. you committed on
branch 1.3 and merged forward all the way to the trunk, then you find
out that an important customer running 1.2 is affected by the bug.  So
you backport the fix with "transplant".

The usual way of phrasing it is that branch N+1 should be a superset
of branch N.  That applies whether you use named branches or separate
repos.

> In that scenario, having one hg
> repository per branch would probably be a workable solution (although
> I have to admit I prefer the git approach of having one huge
> repository for everything, and just use dedicated 'official' branches
> for versions).

Named branches have one huge advantage over both git and
separate-hg-repos: you can tell where the fix was first done.

OTOH, renaming or removing a named branch is extremely difficult.  (It
might as well be impossible.)  So using them for git-style topic
branches (e.g. one branch per bug fix) would be madness.

> More and more though, we have started to build separate sub-projects
> on top of specific releases -- in other words, we are simultaneously
> making a new product on top of v4, while preparing to release v5, and
> getting ready to start work on v6 in earnest, all the while fixing
> bugs across mulitple releases going all the way back to v2.  Its
> getting very complicated :-)

Yeah, that sounds like us too.  The workflow that we're planning to
switch to in January is:

  * one master repository where release branches and production builds
   happen
  * maintenance work is pushed directly to master
  * named branch for each release branch
  * each team (there are 3, of 5-10 developers) has a separate repo
    where they do "trunk work" (e.g. new features): it's a clone of master
    that has to be regularly resynced by the responsible team
  * new features that are more risky or destabilizing get a separate repo
    that is a clone of the team repo

So normally, members of the backend team push to/pull from the
"backend" repository for trunk work, while members of the viewer team
push to/pull from the "viewer" repo.  Anyone doing maintenance work
(low risk, high value, going to customers soon, usually on a stable
branch) pushes directly to the master repo.

If a subset of the viewer team is going to work on risky or
destabilizing feature X for a few weeks, we'll make a new "featureX"
clone of the "viewer" repo, and that sub-team will integrate via
"featureX".

Or at least that's the plan.  I'm itching with curiosity to find out
how it'll all work when the airborne excrement impacts the rotating
ventilation device in a few weeks.

Greg