Mercurial: The Definitive Guide

Chapter 8. Managing Releases and Branchy Development

Mercurial provides several mechanisms for you to manage a project that is progressing on multiple fronts at once. To understand these mechanisms, let’s first take a brief look at a fairly normal software project structure.

Many software projects issue periodic “major” releases that contain substantial new features. In parallel, they may issue “minor” releases. These are usually identical to the major releases off which they’re based, but with a few bugs fixed.

In this chapter, we’ll start by talking about how to keep records of project milestones such as releases. We’ll then continue on to talk about the flow of work between different phases of a project, and how Mercurial can help you to isolate and manage this work.

Giving a Persistent Name to a Revision

Once you decide that you’d like to call a particular revision a “release,” it’s a good idea to record the identity of that revision. This will let you reproduce that release at a later date, for whatever purpose you might need at the time (reproducing a bug, porting to a new platform, etc.).

$ hg init mytag
$ cd mytag
$ echo hello > myfile
$ hg commit -A -m 'Initial commit'
adding myfile

Mercurial lets you give a permanent name to any revision using the hg tag command. Not surprisingly, these names are called “tags.”

$ hg tag v1.0

A tag is nothing more than a “symbolic name” for a revision. Tags exist purely for your convenience, so that you have a handy, permanent way to refer to a ...