hgbook

annotate en/branch.tex @ 281:a880d07f2d29

find changesets by author, revision, files, or words in the commit message
Fix repository paths of data/index files in filelog diagram.

Data/index files are stored in the repository at .hg/store/data, not .hg/data.
Modify the filelog diagram to reflect this.
author Arun Thomas <arun.thomas@gmail.com>
date Mon Dec 17 23:16:59 2007 -0500 (2007-12-17)
parents a24b370a16ee
children c36a6f534b99
rev   line source
bos@196 1 \chapter{Managing releases and branchy development}
bos@187 2 \label{chap:branch}
bos@187 3
bos@197 4 Mercurial provides several mechanisms for you to manage a project that
bos@197 5 is making progress on multiple fronts at once. To understand these
bos@197 6 mechanisms, let's first take a brief look at a fairly normal software
bos@197 7 project structure.
bos@187 8
bos@196 9 Many software projects issue periodic ``major'' releases that contain
bos@196 10 substantial new features. In parallel, they may issue ``minor''
bos@196 11 releases. These are usually identical to the major releases off which
bos@196 12 they're based, but with a few bugs fixed.
bos@196 13
bos@197 14 In this chapter, we'll start by talking about how to keep records of
bos@197 15 project milestones such as releases. We'll then continue on to talk
bos@197 16 about the flow of work between different phases of a project, and how
bos@197 17 Mercurial can help you to isolate and manage this work.
bos@197 18
bos@196 19 \section{Giving a persistent name to a revision}
bos@196 20
bos@196 21 Once you decide that you'd like to call a particular revision a
bos@196 22 ``release'', it's a good idea to record the identity of that revision.
bos@196 23 This will let you reproduce that release at a later date, for whatever
bos@196 24 purpose you might need at the time (reproducing a bug, porting to a
bos@196 25 new platform, etc).
bos@196 26 \interaction{tag.init}
bos@196 27
bos@196 28 Mercurial lets you give a permanent name to any revision using the
bos@196 29 \hgcmd{tag} command. Not surprisingly, these names are called
bos@196 30 ``tags''.
bos@196 31 \interaction{tag.tag}
bos@196 32
bos@196 33 A tag is nothing more than a ``symbolic name'' for a revision. Tags
bos@196 34 exist purely for your convenience, so that you have a handy permanent
bos@196 35 way to refer to a revision; Mercurial doesn't interpret the tag names
bos@196 36 you use in any way. Neither does Mercurial place any restrictions on
bos@196 37 the name of a tag, beyond a few that are necessary to ensure that a
bos@196 38 tag can be parsed unambiguously. A tag name cannot contain any of the
bos@196 39 following characters:
bos@196 40 \begin{itemize}
bos@196 41 \item Colon (ASCII 58, ``\texttt{:}'')
bos@261 42 \item Carriage return (ASCII 13, ``\Verb+\r+'')
bos@261 43 \item Newline (ASCII 10, ``\Verb+\n+'')
bos@196 44 \end{itemize}
bos@196 45
bos@196 46 You can use the \hgcmd{tags} command to display the tags present in
bos@196 47 your repository. In the output, each tagged revision is identified
bos@196 48 first by its name, then by revision number, and finally by the unique
bos@196 49 hash of the revision.
bos@196 50 \interaction{tag.tags}
bos@196 51 Notice that \texttt{tip} is listed in the output of \hgcmd{tags}. The
bos@196 52 \texttt{tip} tag is a special ``floating'' tag, which always
bos@196 53 identifies the newest revision in the repository.
bos@196 54
bos@196 55 In the output of the \hgcmd{tags} command, tags are listed in reverse
bos@196 56 order, by revision number. This usually means that recent tags are
bos@196 57 listed before older tags. It also means that \texttt{tip} is always
bos@196 58 going to be the first tag listed in the output of \hgcmd{tags}.
bos@196 59
bos@196 60 When you run \hgcmd{log}, if it displays a revision that has tags
bos@196 61 associated with it, it will print those tags.
bos@196 62 \interaction{tag.log}
bos@196 63
bos@196 64 Any time you need to provide a revision~ID to a Mercurial command, the
bos@196 65 command will accept a tag name in its place. Internally, Mercurial
bos@196 66 will translate your tag name into the corresponding revision~ID, then
bos@196 67 use that.
bos@196 68 \interaction{tag.log.v1.0}
bos@196 69
bos@196 70 There's no limit on the number of tags you can have in a repository,
bos@196 71 or on the number of tags that a single revision can have. As a
bos@196 72 practical matter, it's not a great idea to have ``too many'' (a number
bos@196 73 which will vary from project to project), simply because tags are
bos@196 74 supposed to help you to find revisions. If you have lots of tags, the
bos@196 75 ease of using them to identify revisions diminishes rapidly.
bos@196 76
bos@196 77 For example, if your project has milestones as frequent as every few
bos@196 78 days, it's perfectly reasonable to tag each one of those. But if you
bos@196 79 have a continuous build system that makes sure every revision can be
bos@196 80 built cleanly, you'd be introducing a lot of noise if you were to tag
bos@196 81 every clean build. Instead, you could tag failed builds (on the
bos@196 82 assumption that they're rare!), or simply not use tags to track
bos@196 83 buildability.
bos@196 84
bos@196 85 If you want to remove a tag that you no longer want, use
bos@196 86 \hgcmdargs{tag}{--remove}.
bos@196 87 \interaction{tag.remove}
bos@196 88 You can also modify a tag at any time, so that it identifies a
bos@196 89 different revision, by simply issuing a new \hgcmd{tag} command.
bos@196 90 You'll have to use the \hgopt{tag}{-f} option to tell Mercurial that
bos@196 91 you \emph{really} want to update the tag.
bos@196 92 \interaction{tag.replace}
bos@196 93 There will still be a permanent record of the previous identity of the
bos@197 94 tag, but Mercurial will no longer use it. There's thus no penalty to
bos@197 95 tagging the wrong revision; all you have to do is turn around and tag
bos@197 96 the correct revision once you discover your error.
bos@196 97
bos@196 98 Mercurial stores tags in a normal revision-controlled file in your
bos@196 99 repository. If you've created any tags, you'll find them in a file
bos@196 100 named \sfilename{.hgtags}. When you run the \hgcmd{tag} command,
bos@196 101 Mercurial modifies this file, then automatically commits the change to
bos@196 102 it. This means that every time you run \hgcmd{tag}, you'll see a
bos@196 103 corresponding changeset in the output of \hgcmd{log}.
bos@196 104 \interaction{tag.tip}
bos@196 105
bos@196 106 \subsection{Handling tag conflicts during a merge}
bos@196 107
bos@196 108 You won't often need to care about the \sfilename{.hgtags} file, but
bos@196 109 it sometimes makes its presence known during a merge. The format of
bos@196 110 the file is simple: it consists of a series of lines. Each line
bos@196 111 starts with a changeset hash, followed by a space, followed by the
bos@196 112 name of a tag.
bos@196 113
bos@196 114 If you're resolving a conflict in the \sfilename{.hgtags} file during
bos@196 115 a merge, there's one twist to modifying the \sfilename{.hgtags} file:
bos@196 116 when Mercurial is parsing the tags in a repository, it \emph{never}
bos@196 117 reads the working copy of the \sfilename{.hgtags} file. Instead, it
bos@196 118 reads the \emph{most recently committed} revision of the file.
bos@196 119
bos@196 120 An unfortunate consequence of this design is that you can't actually
bos@196 121 verify that your merged \sfilename{.hgtags} file is correct until
bos@196 122 \emph{after} you've committed a change. So if you find yourself
bos@196 123 resolving a conflict on \sfilename{.hgtags} during a merge, be sure to
bos@196 124 run \hgcmd{tags} after you commit. If it finds an error in the
bos@196 125 \sfilename{.hgtags} file, it will report the location of the error,
bos@196 126 which you can then fix and commit. You should then run \hgcmd{tags}
bos@196 127 again, just to be sure that your fix is correct.
bos@187 128
bos@198 129 \subsection{Tags and cloning}
bos@198 130
bos@198 131 You may have noticed that the \hgcmd{clone} command has a
wbunaarfubss@259 132 \hgopt{clone}{-r} option that lets you clone an exact copy of the
bos@198 133 repository as of a particular changeset. The new clone will not
bos@198 134 contain any project history that comes after the revision you
bos@198 135 specified. This has an interaction with tags that can surprise the
bos@198 136 unwary.
bos@198 137
bos@198 138 Recall that a tag is stored as a revision to the \sfilename{.hgtags}
bos@198 139 file, so that when you create a tag, the changeset in which it's
bos@198 140 recorded necessarily refers to an older changeset. When you run
bos@198 141 \hgcmdargs{clone}{-r foo} to clone a repository as of tag
bos@198 142 \texttt{foo}, the new clone \emph{will not contain the history that
bos@198 143 created the tag} that you used to clone the repository. The result
bos@198 144 is that you'll get exactly the right subset of the project's history
bos@198 145 in the new repository, but \emph{not} the tag you might have expected.
bos@198 146
bos@197 147 \subsection{When permanent tags are too much}
bos@197 148
bos@197 149 Since Mercurial's tags are revision controlled and carried around with
bos@197 150 a project's history, everyone you work with will see the tags you
bos@197 151 create. But giving names to revisions has uses beyond simply noting
bos@197 152 that revision \texttt{4237e45506ee} is really \texttt{v2.0.2}. If
bos@197 153 you're trying to track down a subtle bug, you might want a tag to
bos@197 154 remind you of something like ``Anne saw the symptoms with this
bos@197 155 revision''.
bos@197 156
bos@197 157 For cases like this, what you might want to use are \emph{local} tags.
bos@197 158 You can create a local tag with the \hgopt{tag}{-l} option to the
bos@197 159 \hgcmd{tag} command. This will store the tag in a file called
bos@197 160 \sfilename{.hg/localtags}. Unlike \sfilename{.hgtags},
bos@197 161 \sfilename{.hg/localtags} is not revision controlled. Any tags you
bos@197 162 create using \hgopt{tag}{-l} remain strictly local to the repository
bos@197 163 you're currently working in.
bos@197 164
bos@198 165 \section{The flow of changes---big picture vs. little}
bos@198 166
bos@198 167 To return to the outline I sketched at the beginning of a chapter,
bos@198 168 let's think about a project that has multiple concurrent pieces of
bos@198 169 work under development at once.
bos@198 170
bos@198 171 There might be a push for a new ``main'' release; a new minor bugfix
bos@198 172 release to the last main release; and an unexpected ``hot fix'' to an
bos@198 173 old release that is now in maintenance mode.
bos@198 174
bos@198 175 The usual way people refer to these different concurrent directions of
bos@198 176 development is as ``branches''. However, we've already seen numerous
bos@198 177 times that Mercurial treats \emph{all of history} as a series of
bos@198 178 branches and merges. Really, what we have here is two ideas that are
bos@198 179 peripherally related, but which happen to share a name.
bos@198 180 \begin{itemize}
bos@198 181 \item ``Big picture'' branches represent the sweep of a project's
bos@198 182 evolution; people give them names, and talk about them in
bos@198 183 conversation.
bos@198 184 \item ``Little picture'' branches are artefacts of the day-to-day
bos@198 185 activity of developing and merging changes. They expose the
bos@198 186 narrative of how the code was developed.
bos@198 187 \end{itemize}
bos@198 188
bos@198 189 \section{Managing big-picture branches in repositories}
bos@198 190
bos@198 191 The easiest way to isolate a ``big picture'' branch in Mercurial is in
bos@198 192 a dedicated repository. If you have an existing shared
bos@198 193 repository---let's call it \texttt{myproject}---that reaches a ``1.0''
bos@198 194 milestone, you can start to prepare for future maintenance releases on
bos@198 195 top of version~1.0 by tagging the revision from which you prepared
bos@198 196 the~1.0 release.
bos@198 197 \interaction{branch-repo.tag}
bos@198 198 You can then clone a new shared \texttt{myproject-1.0.1} repository as
bos@198 199 of that tag.
bos@198 200 \interaction{branch-repo.clone}
bos@198 201
bos@198 202 Afterwards, if someone needs to work on a bug fix that ought to go
bos@198 203 into an upcoming~1.0.1 minor release, they clone the
bos@198 204 \texttt{myproject-1.0.1} repository, make their changes, and push them
bos@198 205 back.
bos@198 206 \interaction{branch-repo.bugfix}
bos@198 207 Meanwhile, development for the next major release can continue,
bos@198 208 isolated and unabated, in the \texttt{myproject} repository.
bos@198 209 \interaction{branch-repo.new}
bos@198 210
bos@199 211 \section{Don't repeat yourself: merging across branches}
bos@199 212
bos@199 213 In many cases, if you have a bug to fix on a maintenance branch, the
bos@199 214 chances are good that the bug exists on your project's main branch
bos@199 215 (and possibly other maintenance branches, too). It's a rare developer
bos@199 216 who wants to fix the same bug multiple times, so let's look at a few
bos@199 217 ways that Mercurial can help you to manage these bugfixes without
bos@199 218 duplicating your work.
bos@199 219
bos@199 220 In the simplest instance, all you need to do is pull changes from your
bos@199 221 maintenance branch into your local clone of the target branch.
bos@199 222 \interaction{branch-repo.pull}
bos@199 223 You'll then need to merge the heads of the two branches, and push back
bos@199 224 to the main branch.
bos@199 225 \interaction{branch-repo.merge}
bos@197 226
bos@202 227 \section{Naming branches within one repository}
bos@202 228
bos@202 229 In most instances, isolating branches in repositories is the right
bos@202 230 approach. Its simplicity makes it easy to understand; and so it's
bos@202 231 hard to make mistakes. There's a one-to-one relationship between
bos@202 232 branches you're working in and directories on your system. This lets
bos@202 233 you use normal (non-Mercurial-aware) tools to work on files within a
bos@202 234 branch/repository.
bos@202 235
bos@202 236 If you're more in the ``power user'' category (\emph{and} your
bos@202 237 collaborators are too), there is an alternative way of handling
bos@202 238 branches that you can consider. I've already mentioned the
bos@202 239 human-level distinction between ``small picture'' and ``big picture''
bos@202 240 branches. While Mercurial works with multiple ``small picture''
bos@202 241 branches in a repository all the time (for example after you pull
bos@202 242 changes in, but before you merge them), it can \emph{also} work with
bos@202 243 multiple ``big picture'' branches.
bos@202 244
bos@202 245 The key to working this way is that Mercurial lets you assign a
bos@202 246 persistent \emph{name} to a branch. There always exists a branch
bos@202 247 named \texttt{default}. Even before you start naming branches
bos@202 248 yourself, you can find traces of the \texttt{default} branch if you
bos@202 249 look for them.
bos@202 250
bos@202 251 As an example, when you run the \hgcmd{commit} command, and it pops up
bos@202 252 your editor so that you can enter a commit message, look for a line
bos@202 253 that contains the text ``\texttt{HG: branch default}'' at the bottom.
bos@202 254 This is telling you that your commit will occur on the branch named
bos@202 255 \texttt{default}.
bos@202 256
bos@202 257 To start working with named branches, use the \hgcmd{branches}
bos@202 258 command. This command lists the named branches already present in
bos@203 259 your repository, telling you which changeset is the tip of each.
bos@202 260 \interaction{branch-named.branches}
bos@203 261 Since you haven't created any named branches yet, the only one that
bos@203 262 exists is \texttt{default}.
bos@203 263
bos@203 264 To find out what the ``current'' branch is, run the \hgcmd{branch}
bos@203 265 command, giving it no arguments. This tells you what branch the
bos@203 266 parent of the current changeset is on.
bos@203 267 \interaction{branch-named.branch}
bos@203 268
bos@203 269 To create a new branch, run the \hgcmd{branch} command again. This
bos@203 270 time, give it one argument: the name of the branch you want to create.
bos@203 271 \interaction{branch-named.create}
bos@203 272
bos@203 273 After you've created a branch, you might wonder what effect the
bos@203 274 \hgcmd{branch} command has had. What do the \hgcmd{status} and
bos@203 275 \hgcmd{tip} commands report?
bos@203 276 \interaction{branch-named.status}
bos@203 277 Nothing has changed in the working directory, and there's been no new
bos@203 278 history created. As this suggests, running the \hgcmd{branch} command
bos@203 279 has no permanent effect; it only tells Mercurial what branch name to
bos@203 280 use the \emph{next} time you commit a changeset.
bos@203 281
bos@203 282 When you commit a change, Mercurial records the name of the branch on
bos@203 283 which you committed. Once you've switched from the \texttt{default}
bos@203 284 branch to another and committed, you'll see the name of the new branch
bos@203 285 show up in the output of \hgcmd{log}, \hgcmd{tip}, and other commands
bos@203 286 that display the same kind of output.
bos@203 287 \interaction{branch-named.commit}
bos@203 288 The \hgcmd{log}-like commands will print the branch name of every
bos@205 289 changeset that's not on the \texttt{default} branch. As a result, if
bos@205 290 you never use named branches, you'll never see this information.
bos@205 291
bos@205 292 Once you've named a branch and committed a change with that name,
bos@205 293 every subsequent commit that descends from that change will inherit
bos@206 294 the same branch name. You can change the name of a branch at any
bos@206 295 time, using the \hgcmd{branch} command.
bos@206 296 \interaction{branch-named.rebranch}
bos@206 297 In practice, this is something you won't do very often, as branch
bos@206 298 names tend to have fairly long lifetimes. (This isn't a rule, just an
bos@206 299 observation.)
bos@206 300
bos@206 301 \section{Dealing with multiple named branches in a repository}
bos@206 302
bos@206 303 If you have more than one named branch in a repository, Mercurial will
bos@206 304 remember the branch that your working directory on when you start a
bos@206 305 command like \hgcmd{update} or \hgcmdargs{pull}{-u}. It will update
bos@206 306 the working directory to the tip of this branch, no matter what the
bos@206 307 ``repo-wide'' tip is. To update to a revision that's on a different
bos@206 308 named branch, you may need to use the \hgopt{update}{-C} option to
bos@206 309 \hgcmd{update}.
bos@206 310
bos@206 311 This behaviour is a little subtle, so let's see it in action. First,
bos@206 312 let's remind ourselves what branch we're currently on, and what
bos@206 313 branches are in our repository.
bos@206 314 \interaction{branch-named.parents}
bos@206 315 We're on the \texttt{bar} branch, but there also exists an older
bos@206 316 \hgcmd{foo} branch.
bos@206 317
bos@206 318 We can \hgcmd{update} back and forth between the tips of the
bos@206 319 \texttt{foo} and \texttt{bar} branches without needing to use the
bos@206 320 \hgopt{update}{-C} option, because this only involves going backwards
bos@206 321 and forwards linearly through our change history.
bos@206 322 \interaction{branch-named.update-switchy}
bos@206 323
bos@206 324 If we go back to the \texttt{foo} branch and then run \hgcmd{update},
bos@206 325 it will keep us on \texttt{foo}, not move us to the tip of
bos@206 326 \texttt{bar}.
bos@206 327 \interaction{branch-named.update-nothing}
bos@206 328
bos@206 329 Committing a new change on the \texttt{foo} branch introduces a new
bos@206 330 head.
bos@206 331 \interaction{branch-named.foo-commit}
bos@206 332 We can no longer update from \texttt{foo} to \texttt{bar} without
bos@206 333 going ``sideways'' in history, so Mercurial forces us to provide the
bos@206 334 \hgopt{update}{-C} option to \hgcmd{update}.
bos@206 335 \interaction{branch-named.update-bar}
bos@205 336
bos@205 337 \section{Branch names and merging}
bos@205 338
bos@205 339 As you've probably noticed, merges in Mercurial are not symmetrical.
bos@205 340 Let's say our repository has two heads, 17 and 23. If I
bos@205 341 \hgcmd{update} to 17 and then \hgcmd{merge} with 23, Mercurial records
bos@205 342 17 as the first parent of the merge, and 23 as the second. Whereas if
bos@205 343 I \hgcmd{update} to 23 and then \hgcmd{merge} with 17, it records 23
bos@205 344 as the first parent, and 17 as the second.
bos@205 345
bos@206 346 This affects Mercurial's choice of branch name when you merge. After
bos@206 347 a merge, Mercurial will retain the branch name of the first parent
bos@206 348 when you commit the result of the merge. If your first parent's
bos@206 349 branch name is \texttt{foo}, and you merge with \texttt{bar}, the
bos@206 350 branch name will still be \texttt{foo} after you merge.
bos@206 351
bos@206 352 It's not unusual for a repository to contain multiple heads, each with
bos@206 353 the same branch name. Let's say I'm working on the \texttt{foo}
bos@206 354 branch, and so are you. We commit different changes; I pull your
bos@206 355 changes; I now have two heads, each claiming to be on the \texttt{foo}
bos@206 356 branch. The result of a merge will be a single head on the
bos@206 357 \texttt{foo} branch, as you might hope.
bos@206 358
bos@206 359 But if I'm working on the \texttt{bar} branch, and I merge work from
bos@206 360 the \texttt{foo} branch, the result will remain on the \texttt{bar}
bos@206 361 branch.
bos@206 362 \interaction{branch-named.merge}
bos@206 363
bos@206 364 To give a more concrete example, if I'm working on the
bos@206 365 \texttt{bleeding-edge} branch, and I want to bring in the latest fixes
bos@206 366 from the \texttt{stable} branch, Mercurial will choose the ``right''
bos@206 367 (\texttt{bleeding-edge}) branch name when I pull and merge from
bos@206 368 \texttt{stable}.
bos@206 369
bos@206 370 \section{Branch naming is generally useful}
bos@206 371
bos@206 372 You shouldn't think of named branches as applicable only to situations
bos@206 373 where you have multiple long-lived branches cohabiting in a single
bos@206 374 repository. They're very useful even in the one-branch-per-repository
bos@206 375 case.
bos@206 376
bos@206 377 In the simplest case, giving a name to each branch gives you a
bos@206 378 permanent record of which branch a changeset originated on. This
bab@266 379 gives you more context when you're trying to follow the history of a
bos@206 380 long-lived branchy project.
bos@206 381
bos@207 382 If you're working with shared repositories, you can set up a
bos@207 383 \hook{pretxnchangegroup} hook on each that will block incoming changes
bos@207 384 that have the ``wrong'' branch name. This provides a simple, but
bos@207 385 effective, defence against people accidentally pushing changes from a
bos@207 386 ``bleeding edge'' branch to a ``stable'' branch. Such a hook might
bos@207 387 look like this inside the shared repo's \hgrc.
bos@207 388 \begin{codesample2}
bos@207 389 [hooks]
bos@207 390 pretxnchangegroup.branch = hg heads --template '{branches} ' | grep mybranch
bos@207 391 \end{codesample2}
bos@202 392
bos@187 393 %%% Local Variables:
bos@187 394 %%% mode: latex
bos@187 395 %%% TeX-master: "00book"
bos@187 396 %%% End: