1

At my office, we are transitioning away from Visual Source Safe (6.0!) to Mercurial and I am trying to figure the best "Mercurial" way of handling our situation. Currently, in any given project repository, we maintain multiple versions of it: i.e. for Project A, we have a VSS Repo for ProjA-Dev, ProjA-Rel1, and ProjA-Rel2 (a dev repo and one for each of the past two releases).

As it stands now, (nearly) all new work is carried out in the dev repo, then changes that are deemed necessary to be rolled back to Rel1 or Rel2 are done so by hand (files checked out of VSS to their own working directory, then using some diff tool only copying the appropriate changes). At some point, it is deemed that a new release will come out, so the dev repo is cloned and it becomes Proj*-Rev1, and the previous Proj*-Rev1 becomes Proj*-Rev2, and Proj*-Dev just goes on as if nothing has happened. It seems to me that there must be a better way to accomplish this in a much more modern tool such as Mercurial.

My current thought is that each project should have its own repository and the Dev/Rel1/Rel2 distinctions are best handled by different named branches. However, what I cannot figure out/see/wrap my head around is how to accomplish our current workflow under such an environment. If we follow our current workflow, then work continues unabated in the dev-branch and certain changes (not all!) are rolled back/over to the Rel branches. I know this can be accomplished via the transplant/graft functionality of Mercurial, which doesn't yet seem to be nicely supported in TortoiseHg. And, more importantly, past answers seem to suggest that the best solution to this is to not allow things to get into such a state to begin with 1.

Question is, what is the best way to avoid such a state given the current workflow? I have read numerous guides about Mercurial and branching (including many, many responses found on here) but have not seen a clear cut answer to this question.

Community
  • 1
  • 1
Matt Ford
  • 46
  • 7
  • One concept which handles this is promotion groups, whereby the dev/test/rel cycle can be thought of as a quality dimension (of the same code 'leaf') which is orthogonal to the normal 'feature set' type of branching. I'm not familiar with Mercurial so can't help directly. e.g. http://www.ericsink.com/scm/scm_branches.html – StuartLC Jul 03 '12 at 04:22
  • 1
    Why wouldn't something in DEV be released? I'm not trying to be obtuse, just understand the reasoning. If it's because a feature is unfinished, then maybe that work should have been done on it's own "branch" (not necessarily a "named branch"). I think the key is that feature branches tend to happen quite naturally in DVCSs, so unless someone is deliberately pushing unfinished work to DEV, you shouldn't have too many things in DEV that don't move to RELEASE. – Paul S Jul 03 '12 at 15:14

1 Answers1

6

I don't know if this will suit you exactly, but I can give you some information about how Mozilla uses Mercurial. We release Firefox every six weeks, and we have several different branches that run in parallel: "nightly" builds from the mozilla-central repository, where all active development happens, "aurora" builds from the mozilla-aurora repository, where we try to stabilize the code for release, "beta" builds from the mozilla-beta repository, where we perform final validation, and release builds from the mozilla-release repository. Each of these repositories is maintained as a separate clone.

The actual branch mechanics of moving from one branch to another are somewhat complicated. The branches all share a common history, but since the aurora and beta branches get selected security and stability fixes transplanted to them in the run-up to release, they have divergent history. The exact process is documented in the link at the start of this paragraph, but it boils down to: "tag the mozilla-central repository; tag and close the current head of mozilla-aurora; push mozilla-central to mozilla-aurora as a new head". The same process is repeated for aurora->beta.

Backporting fixes from development to the aurora or beta branches is just a matter of transplanting changesets. You can use the hg transplant command for that if you'd like, I documented how I do it on my blog.

All that being said, this may be overkill for most projects. We use separate repository clones instead of named branches because our tooling for named branches wasn't great, and we actually prefer the isolation it gives us. You could use named branches for a lighter-weight process here, simply create a new named branch off of the default branch when you're ready, and backport fixes there as-needed while development continues on default.

Ted Mielczarek
  • 3,919
  • 26
  • 32