bos@196: \chapter{Managing releases and branchy development} bos@187: \label{chap:branch} bos@187: bos@197: Mercurial provides several mechanisms for you to manage a project that bos@197: is making progress on multiple fronts at once. To understand these bos@197: mechanisms, let's first take a brief look at a fairly normal software bos@197: project structure. bos@187: bos@196: Many software projects issue periodic ``major'' releases that contain bos@196: substantial new features. In parallel, they may issue ``minor'' bos@196: releases. These are usually identical to the major releases off which bos@196: they're based, but with a few bugs fixed. bos@196: bos@197: In this chapter, we'll start by talking about how to keep records of bos@197: project milestones such as releases. We'll then continue on to talk bos@197: about the flow of work between different phases of a project, and how bos@197: Mercurial can help you to isolate and manage this work. bos@197: bos@196: \section{Giving a persistent name to a revision} bos@196: bos@196: Once you decide that you'd like to call a particular revision a bos@196: ``release'', it's a good idea to record the identity of that revision. bos@196: This will let you reproduce that release at a later date, for whatever bos@196: purpose you might need at the time (reproducing a bug, porting to a bos@196: new platform, etc). bos@196: \interaction{tag.init} bos@196: bos@196: Mercurial lets you give a permanent name to any revision using the bos@196: \hgcmd{tag} command. Not surprisingly, these names are called bos@196: ``tags''. bos@196: \interaction{tag.tag} bos@196: bos@196: A tag is nothing more than a ``symbolic name'' for a revision. Tags bos@196: exist purely for your convenience, so that you have a handy permanent bos@196: way to refer to a revision; Mercurial doesn't interpret the tag names bos@196: you use in any way. Neither does Mercurial place any restrictions on bos@196: the name of a tag, beyond a few that are necessary to ensure that a bos@196: tag can be parsed unambiguously. A tag name cannot contain any of the bos@196: following characters: bos@196: \begin{itemize} bos@196: \item Colon (ASCII 58, ``\texttt{:}'') bos@261: \item Carriage return (ASCII 13, ``\Verb+\r+'') bos@261: \item Newline (ASCII 10, ``\Verb+\n+'') bos@196: \end{itemize} bos@196: bos@196: You can use the \hgcmd{tags} command to display the tags present in bos@196: your repository. In the output, each tagged revision is identified bos@196: first by its name, then by revision number, and finally by the unique bos@196: hash of the revision. bos@196: \interaction{tag.tags} bos@196: Notice that \texttt{tip} is listed in the output of \hgcmd{tags}. The bos@196: \texttt{tip} tag is a special ``floating'' tag, which always bos@196: identifies the newest revision in the repository. bos@196: bos@196: In the output of the \hgcmd{tags} command, tags are listed in reverse bos@196: order, by revision number. This usually means that recent tags are bos@196: listed before older tags. It also means that \texttt{tip} is always bos@196: going to be the first tag listed in the output of \hgcmd{tags}. bos@196: bos@196: When you run \hgcmd{log}, if it displays a revision that has tags bos@196: associated with it, it will print those tags. bos@196: \interaction{tag.log} bos@196: bos@196: Any time you need to provide a revision~ID to a Mercurial command, the bos@196: command will accept a tag name in its place. Internally, Mercurial bos@196: will translate your tag name into the corresponding revision~ID, then bos@196: use that. bos@196: \interaction{tag.log.v1.0} bos@196: bos@196: There's no limit on the number of tags you can have in a repository, bos@196: or on the number of tags that a single revision can have. As a bos@196: practical matter, it's not a great idea to have ``too many'' (a number bos@196: which will vary from project to project), simply because tags are bos@196: supposed to help you to find revisions. If you have lots of tags, the bos@196: ease of using them to identify revisions diminishes rapidly. bos@196: bos@196: For example, if your project has milestones as frequent as every few bos@196: days, it's perfectly reasonable to tag each one of those. But if you bos@196: have a continuous build system that makes sure every revision can be bos@196: built cleanly, you'd be introducing a lot of noise if you were to tag bos@196: every clean build. Instead, you could tag failed builds (on the bos@196: assumption that they're rare!), or simply not use tags to track bos@196: buildability. bos@196: bos@196: If you want to remove a tag that you no longer want, use bos@196: \hgcmdargs{tag}{--remove}. bos@196: \interaction{tag.remove} bos@196: You can also modify a tag at any time, so that it identifies a bos@196: different revision, by simply issuing a new \hgcmd{tag} command. bos@196: You'll have to use the \hgopt{tag}{-f} option to tell Mercurial that bos@196: you \emph{really} want to update the tag. bos@196: \interaction{tag.replace} bos@196: There will still be a permanent record of the previous identity of the bos@197: tag, but Mercurial will no longer use it. There's thus no penalty to bos@197: tagging the wrong revision; all you have to do is turn around and tag bos@197: the correct revision once you discover your error. bos@196: bos@196: Mercurial stores tags in a normal revision-controlled file in your bos@196: repository. If you've created any tags, you'll find them in a file bos@196: named \sfilename{.hgtags}. When you run the \hgcmd{tag} command, bos@196: Mercurial modifies this file, then automatically commits the change to bos@196: it. This means that every time you run \hgcmd{tag}, you'll see a bos@196: corresponding changeset in the output of \hgcmd{log}. bos@196: \interaction{tag.tip} bos@196: bos@196: \subsection{Handling tag conflicts during a merge} bos@196: bos@196: You won't often need to care about the \sfilename{.hgtags} file, but bos@196: it sometimes makes its presence known during a merge. The format of bos@196: the file is simple: it consists of a series of lines. Each line bos@196: starts with a changeset hash, followed by a space, followed by the bos@196: name of a tag. bos@196: bos@196: If you're resolving a conflict in the \sfilename{.hgtags} file during bos@196: a merge, there's one twist to modifying the \sfilename{.hgtags} file: bos@196: when Mercurial is parsing the tags in a repository, it \emph{never} bos@196: reads the working copy of the \sfilename{.hgtags} file. Instead, it bos@196: reads the \emph{most recently committed} revision of the file. bos@196: bos@196: An unfortunate consequence of this design is that you can't actually bos@196: verify that your merged \sfilename{.hgtags} file is correct until bos@196: \emph{after} you've committed a change. So if you find yourself bos@196: resolving a conflict on \sfilename{.hgtags} during a merge, be sure to bos@196: run \hgcmd{tags} after you commit. If it finds an error in the bos@196: \sfilename{.hgtags} file, it will report the location of the error, bos@196: which you can then fix and commit. You should then run \hgcmd{tags} bos@196: again, just to be sure that your fix is correct. bos@187: bos@198: \subsection{Tags and cloning} bos@198: bos@198: You may have noticed that the \hgcmd{clone} command has a wbunaarfubss@259: \hgopt{clone}{-r} option that lets you clone an exact copy of the bos@198: repository as of a particular changeset. The new clone will not bos@198: contain any project history that comes after the revision you bos@198: specified. This has an interaction with tags that can surprise the bos@198: unwary. bos@198: bos@198: Recall that a tag is stored as a revision to the \sfilename{.hgtags} bos@198: file, so that when you create a tag, the changeset in which it's bos@198: recorded necessarily refers to an older changeset. When you run bos@198: \hgcmdargs{clone}{-r foo} to clone a repository as of tag bos@198: \texttt{foo}, the new clone \emph{will not contain the history that bos@198: created the tag} that you used to clone the repository. The result bos@198: is that you'll get exactly the right subset of the project's history bos@198: in the new repository, but \emph{not} the tag you might have expected. bos@198: bos@197: \subsection{When permanent tags are too much} bos@197: bos@197: Since Mercurial's tags are revision controlled and carried around with bos@197: a project's history, everyone you work with will see the tags you bos@197: create. But giving names to revisions has uses beyond simply noting bos@197: that revision \texttt{4237e45506ee} is really \texttt{v2.0.2}. If bos@197: you're trying to track down a subtle bug, you might want a tag to bos@197: remind you of something like ``Anne saw the symptoms with this bos@197: revision''. bos@197: bos@197: For cases like this, what you might want to use are \emph{local} tags. bos@197: You can create a local tag with the \hgopt{tag}{-l} option to the bos@197: \hgcmd{tag} command. This will store the tag in a file called bos@197: \sfilename{.hg/localtags}. Unlike \sfilename{.hgtags}, bos@197: \sfilename{.hg/localtags} is not revision controlled. Any tags you bos@197: create using \hgopt{tag}{-l} remain strictly local to the repository bos@197: you're currently working in. bos@197: bos@198: \section{The flow of changes---big picture vs. little} bos@198: bos@198: To return to the outline I sketched at the beginning of a chapter, bos@198: let's think about a project that has multiple concurrent pieces of bos@198: work under development at once. bos@198: bos@198: There might be a push for a new ``main'' release; a new minor bugfix bos@198: release to the last main release; and an unexpected ``hot fix'' to an bos@198: old release that is now in maintenance mode. bos@198: bos@198: The usual way people refer to these different concurrent directions of bos@198: development is as ``branches''. However, we've already seen numerous bos@198: times that Mercurial treats \emph{all of history} as a series of bos@198: branches and merges. Really, what we have here is two ideas that are bos@198: peripherally related, but which happen to share a name. bos@198: \begin{itemize} bos@198: \item ``Big picture'' branches represent the sweep of a project's bos@198: evolution; people give them names, and talk about them in bos@198: conversation. bos@198: \item ``Little picture'' branches are artefacts of the day-to-day bos@198: activity of developing and merging changes. They expose the bos@198: narrative of how the code was developed. bos@198: \end{itemize} bos@198: bos@198: \section{Managing big-picture branches in repositories} bos@198: bos@198: The easiest way to isolate a ``big picture'' branch in Mercurial is in bos@198: a dedicated repository. If you have an existing shared bos@198: repository---let's call it \texttt{myproject}---that reaches a ``1.0'' bos@198: milestone, you can start to prepare for future maintenance releases on bos@198: top of version~1.0 by tagging the revision from which you prepared bos@198: the~1.0 release. bos@198: \interaction{branch-repo.tag} bos@198: You can then clone a new shared \texttt{myproject-1.0.1} repository as bos@198: of that tag. bos@198: \interaction{branch-repo.clone} bos@198: bos@198: Afterwards, if someone needs to work on a bug fix that ought to go bos@198: into an upcoming~1.0.1 minor release, they clone the bos@198: \texttt{myproject-1.0.1} repository, make their changes, and push them bos@198: back. bos@198: \interaction{branch-repo.bugfix} bos@198: Meanwhile, development for the next major release can continue, bos@198: isolated and unabated, in the \texttt{myproject} repository. bos@198: \interaction{branch-repo.new} bos@198: bos@199: \section{Don't repeat yourself: merging across branches} bos@199: bos@199: In many cases, if you have a bug to fix on a maintenance branch, the bos@199: chances are good that the bug exists on your project's main branch bos@199: (and possibly other maintenance branches, too). It's a rare developer bos@199: who wants to fix the same bug multiple times, so let's look at a few bos@199: ways that Mercurial can help you to manage these bugfixes without bos@199: duplicating your work. bos@199: bos@199: In the simplest instance, all you need to do is pull changes from your bos@199: maintenance branch into your local clone of the target branch. bos@199: \interaction{branch-repo.pull} bos@199: You'll then need to merge the heads of the two branches, and push back bos@199: to the main branch. bos@199: \interaction{branch-repo.merge} bos@197: bos@202: \section{Naming branches within one repository} bos@202: bos@202: In most instances, isolating branches in repositories is the right bos@202: approach. Its simplicity makes it easy to understand; and so it's bos@202: hard to make mistakes. There's a one-to-one relationship between bos@202: branches you're working in and directories on your system. This lets bos@202: you use normal (non-Mercurial-aware) tools to work on files within a bos@202: branch/repository. bos@202: bos@202: If you're more in the ``power user'' category (\emph{and} your bos@202: collaborators are too), there is an alternative way of handling bos@202: branches that you can consider. I've already mentioned the bos@202: human-level distinction between ``small picture'' and ``big picture'' bos@202: branches. While Mercurial works with multiple ``small picture'' bos@202: branches in a repository all the time (for example after you pull bos@202: changes in, but before you merge them), it can \emph{also} work with bos@202: multiple ``big picture'' branches. bos@202: bos@202: The key to working this way is that Mercurial lets you assign a bos@202: persistent \emph{name} to a branch. There always exists a branch bos@202: named \texttt{default}. Even before you start naming branches bos@202: yourself, you can find traces of the \texttt{default} branch if you bos@202: look for them. bos@202: bos@202: As an example, when you run the \hgcmd{commit} command, and it pops up bos@202: your editor so that you can enter a commit message, look for a line bos@202: that contains the text ``\texttt{HG: branch default}'' at the bottom. bos@202: This is telling you that your commit will occur on the branch named bos@202: \texttt{default}. bos@202: bos@202: To start working with named branches, use the \hgcmd{branches} bos@202: command. This command lists the named branches already present in bos@203: your repository, telling you which changeset is the tip of each. bos@202: \interaction{branch-named.branches} bos@203: Since you haven't created any named branches yet, the only one that bos@203: exists is \texttt{default}. bos@203: bos@203: To find out what the ``current'' branch is, run the \hgcmd{branch} bos@203: command, giving it no arguments. This tells you what branch the bos@203: parent of the current changeset is on. bos@203: \interaction{branch-named.branch} bos@203: bos@203: To create a new branch, run the \hgcmd{branch} command again. This bos@203: time, give it one argument: the name of the branch you want to create. bos@203: \interaction{branch-named.create} bos@203: bos@203: After you've created a branch, you might wonder what effect the bos@203: \hgcmd{branch} command has had. What do the \hgcmd{status} and bos@203: \hgcmd{tip} commands report? bos@203: \interaction{branch-named.status} bos@203: Nothing has changed in the working directory, and there's been no new bos@203: history created. As this suggests, running the \hgcmd{branch} command bos@203: has no permanent effect; it only tells Mercurial what branch name to bos@203: use the \emph{next} time you commit a changeset. bos@203: bos@203: When you commit a change, Mercurial records the name of the branch on bos@203: which you committed. Once you've switched from the \texttt{default} bos@203: branch to another and committed, you'll see the name of the new branch bos@203: show up in the output of \hgcmd{log}, \hgcmd{tip}, and other commands bos@203: that display the same kind of output. bos@203: \interaction{branch-named.commit} bos@203: The \hgcmd{log}-like commands will print the branch name of every bos@205: changeset that's not on the \texttt{default} branch. As a result, if bos@205: you never use named branches, you'll never see this information. bos@205: bos@205: Once you've named a branch and committed a change with that name, bos@205: every subsequent commit that descends from that change will inherit bos@206: the same branch name. You can change the name of a branch at any bos@206: time, using the \hgcmd{branch} command. bos@206: \interaction{branch-named.rebranch} bos@206: In practice, this is something you won't do very often, as branch bos@206: names tend to have fairly long lifetimes. (This isn't a rule, just an bos@206: observation.) bos@206: bos@206: \section{Dealing with multiple named branches in a repository} bos@206: bos@206: If you have more than one named branch in a repository, Mercurial will bos@206: remember the branch that your working directory on when you start a bos@206: command like \hgcmd{update} or \hgcmdargs{pull}{-u}. It will update bos@206: the working directory to the tip of this branch, no matter what the bos@206: ``repo-wide'' tip is. To update to a revision that's on a different bos@206: named branch, you may need to use the \hgopt{update}{-C} option to bos@206: \hgcmd{update}. bos@206: bos@206: This behaviour is a little subtle, so let's see it in action. First, bos@206: let's remind ourselves what branch we're currently on, and what bos@206: branches are in our repository. bos@206: \interaction{branch-named.parents} bos@206: We're on the \texttt{bar} branch, but there also exists an older bos@206: \hgcmd{foo} branch. bos@206: bos@206: We can \hgcmd{update} back and forth between the tips of the bos@206: \texttt{foo} and \texttt{bar} branches without needing to use the bos@206: \hgopt{update}{-C} option, because this only involves going backwards bos@206: and forwards linearly through our change history. bos@206: \interaction{branch-named.update-switchy} bos@206: bos@206: If we go back to the \texttt{foo} branch and then run \hgcmd{update}, bos@206: it will keep us on \texttt{foo}, not move us to the tip of bos@206: \texttt{bar}. bos@206: \interaction{branch-named.update-nothing} bos@206: bos@206: Committing a new change on the \texttt{foo} branch introduces a new bos@206: head. bos@206: \interaction{branch-named.foo-commit} bos@206: We can no longer update from \texttt{foo} to \texttt{bar} without bos@206: going ``sideways'' in history, so Mercurial forces us to provide the bos@206: \hgopt{update}{-C} option to \hgcmd{update}. bos@206: \interaction{branch-named.update-bar} bos@205: bos@205: \section{Branch names and merging} bos@205: bos@205: As you've probably noticed, merges in Mercurial are not symmetrical. bos@205: Let's say our repository has two heads, 17 and 23. If I bos@205: \hgcmd{update} to 17 and then \hgcmd{merge} with 23, Mercurial records bos@205: 17 as the first parent of the merge, and 23 as the second. Whereas if bos@205: I \hgcmd{update} to 23 and then \hgcmd{merge} with 17, it records 23 bos@205: as the first parent, and 17 as the second. bos@205: bos@206: This affects Mercurial's choice of branch name when you merge. After bos@206: a merge, Mercurial will retain the branch name of the first parent bos@206: when you commit the result of the merge. If your first parent's bos@206: branch name is \texttt{foo}, and you merge with \texttt{bar}, the bos@206: branch name will still be \texttt{foo} after you merge. bos@206: bos@206: It's not unusual for a repository to contain multiple heads, each with bos@206: the same branch name. Let's say I'm working on the \texttt{foo} bos@206: branch, and so are you. We commit different changes; I pull your bos@206: changes; I now have two heads, each claiming to be on the \texttt{foo} bos@206: branch. The result of a merge will be a single head on the bos@206: \texttt{foo} branch, as you might hope. bos@206: bos@206: But if I'm working on the \texttt{bar} branch, and I merge work from bos@206: the \texttt{foo} branch, the result will remain on the \texttt{bar} bos@206: branch. bos@206: \interaction{branch-named.merge} bos@206: bos@206: To give a more concrete example, if I'm working on the bos@206: \texttt{bleeding-edge} branch, and I want to bring in the latest fixes bos@206: from the \texttt{stable} branch, Mercurial will choose the ``right'' bos@206: (\texttt{bleeding-edge}) branch name when I pull and merge from bos@206: \texttt{stable}. bos@206: bos@206: \section{Branch naming is generally useful} bos@206: bos@206: You shouldn't think of named branches as applicable only to situations bos@206: where you have multiple long-lived branches cohabiting in a single bos@206: repository. They're very useful even in the one-branch-per-repository bos@206: case. bos@206: bos@206: In the simplest case, giving a name to each branch gives you a bos@206: permanent record of which branch a changeset originated on. This bab@266: gives you more context when you're trying to follow the history of a bos@206: long-lived branchy project. bos@206: bos@207: If you're working with shared repositories, you can set up a bos@207: \hook{pretxnchangegroup} hook on each that will block incoming changes bos@207: that have the ``wrong'' branch name. This provides a simple, but bos@207: effective, defence against people accidentally pushing changes from a bos@207: ``bleeding edge'' branch to a ``stable'' branch. Such a hook might bos@207: look like this inside the shared repo's \hgrc. bos@207: \begin{codesample2} bos@207: [hooks] bos@207: pretxnchangegroup.branch = hg heads --template '{branches} ' | grep mybranch bos@207: \end{codesample2} bos@202: bos@187: %%% Local Variables: bos@187: %%% mode: latex bos@187: %%% TeX-master: "00book" bos@187: %%% End: