1.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     1.2 +++ b/fr/ch08-branch.xml	Sun Aug 16 04:58:01 2009 +0200
     1.3 @@ -0,0 +1,473 @@
     1.4 +<!-- vim: set filetype=docbkxml shiftwidth=2 autoindent expandtab tw=77 : -->
     1.5 +
     1.6 +<chapter>
     1.7 +<title>Managing releases and branchy development</title>
     1.8 +<para>\label{chap:branch}</para>
     1.9 +
    1.10 +<para>Mercurial provides several mechanisms for you to manage a project that
    1.11 +is making progress on multiple fronts at once.  To understand these
    1.12 +mechanisms, let's first take a brief look at a fairly normal software
    1.13 +project structure.</para>
    1.14 +
    1.15 +<para>Many software projects issue periodic <quote>major</quote> releases that contain
    1.16 +substantial new features.  In parallel, they may issue <quote>minor</quote>
    1.17 +releases.  These are usually identical to the major releases off which
    1.18 +they're based, but with a few bugs fixed.</para>
    1.19 +
    1.20 +<para>In this chapter, we'll start by talking about how to keep records of
    1.21 +project milestones such as releases.  We'll then continue on to talk
    1.22 +about the flow of work between different phases of a project, and how
    1.23 +Mercurial can help you to isolate and manage this work.</para>
    1.24 +
    1.25 +<sect1>
    1.26 +<title>Giving a persistent name to a revision</title>
    1.27 +
    1.28 +<para>Once you decide that you'd like to call a particular revision a
    1.29 +<quote>release</quote>, it's a good idea to record the identity of that revision.
    1.30 +This will let you reproduce that release at a later date, for whatever
    1.31 +purpose you might need at the time (reproducing a bug, porting to a
    1.32 +new platform, etc).
    1.33 +<!-- &interaction.tag.init; --></para>
    1.34 +
    1.35 +<para>Mercurial lets you give a permanent name to any revision using the
    1.36 +<command role="hg-cmd">hg tag</command> command.  Not surprisingly, these names are called
    1.37 +<quote>tags</quote>.
    1.38 +<!-- &interaction.tag.tag; --></para>
    1.39 +
    1.40 +<para>A tag is nothing more than a <quote>symbolic name</quote> for a revision.  Tags
    1.41 +exist purely for your convenience, so that you have a handy permanent
    1.42 +way to refer to a revision; Mercurial doesn't interpret the tag names
    1.43 +you use in any way.  Neither does Mercurial place any restrictions on
    1.44 +the name of a tag, beyond a few that are necessary to ensure that a
    1.45 +tag can be parsed unambiguously.  A tag name cannot contain any of the
    1.46 +following characters:</para>
    1.47 +<itemizedlist>
    1.48 +<listitem><para>Colon (ASCII 58, <quote><literal>:</literal></quote>)</para>
    1.49 +</listitem>
    1.50 +<listitem><para>Carriage return (ASCII 13, <quote><literal>\r</literal></quote>)
    1.51 +</para>
    1.52 +</listitem>
    1.53 +<listitem><para>Newline (ASCII 10, <quote><literal>\n</literal></quote>)
    1.54 +</para>
    1.55 +</listitem></itemizedlist>
    1.56 +
    1.57 +<para>You can use the <command role="hg-cmd">hg tags</command> command to display the tags present in
    1.58 +your repository.  In the output, each tagged revision is identified
    1.59 +first by its name, then by revision number, and finally by the unique
    1.60 +hash of the revision.
    1.61 +<!-- &interaction.tag.tags; -->
    1.62 +Notice that <literal>tip</literal> is listed in the output of <command role="hg-cmd">hg tags</command>.  The
    1.63 +<literal>tip</literal> tag is a special <quote>floating</quote> tag, which always
    1.64 +identifies the newest revision in the repository.
    1.65 +</para>
    1.66 +
    1.67 +<para>In the output of the <command role="hg-cmd">hg tags</command> command, tags are listed in reverse
    1.68 +order, by revision number.  This usually means that recent tags are
    1.69 +listed before older tags.  It also means that <literal>tip</literal> is always
    1.70 +going to be the first tag listed in the output of <command role="hg-cmd">hg tags</command>.
    1.71 +</para>
    1.72 +
    1.73 +<para>When you run <command role="hg-cmd">hg log</command>, if it displays a revision that has tags
    1.74 +associated with it, it will print those tags.
    1.75 +<!-- &interaction.tag.log; -->
    1.76 +</para>
    1.77 +
    1.78 +<para>Any time you need to provide a revision ID to a Mercurial command, the
    1.79 +command will accept a tag name in its place.  Internally, Mercurial
    1.80 +will translate your tag name into the corresponding revision ID, then
    1.81 +use that.
    1.82 +<!-- &interaction.tag.log.v1.0; -->
    1.83 +</para>
    1.84 +
    1.85 +<para>There's no limit on the number of tags you can have in a repository,
    1.86 +or on the number of tags that a single revision can have.  As a
    1.87 +practical matter, it's not a great idea to have <quote>too many</quote> (a number
    1.88 +which will vary from project to project), simply because tags are
    1.89 +supposed to help you to find revisions.  If you have lots of tags, the
    1.90 +ease of using them to identify revisions diminishes rapidly.
    1.91 +</para>
    1.92 +
    1.93 +<para>For example, if your project has milestones as frequent as every few
    1.94 +days, it's perfectly reasonable to tag each one of those.  But if you
    1.95 +have a continuous build system that makes sure every revision can be
    1.96 +built cleanly, you'd be introducing a lot of noise if you were to tag
    1.97 +every clean build.  Instead, you could tag failed builds (on the
    1.98 +assumption that they're rare!), or simply not use tags to track
    1.99 +buildability.
   1.100 +</para>
   1.101 +
   1.102 +<para>If you want to remove a tag that you no longer want, use
   1.103 +<command role="hg-cmd">hg tag --remove</command>.
   1.104 +<!-- &interaction.tag.remove; -->
   1.105 +You can also modify a tag at any time, so that it identifies a
   1.106 +different revision, by simply issuing a new <command role="hg-cmd">hg tag</command> command.
   1.107 +You'll have to use the <option role="hg-opt-tag">-f</option> option to tell Mercurial that
   1.108 +you <emphasis>really</emphasis> want to update the tag.
   1.109 +<!-- &interaction.tag.replace; -->
   1.110 +There will still be a permanent record of the previous identity of the
   1.111 +tag, but Mercurial will no longer use it.  There's thus no penalty to
   1.112 +tagging the wrong revision; all you have to do is turn around and tag
   1.113 +the correct revision once you discover your error.
   1.114 +</para>
   1.115 +
   1.116 +<para>Mercurial stores tags in a normal revision-controlled file in your
   1.117 +repository.  If you've created any tags, you'll find them in a file
   1.118 +named <filename role="special">.hgtags</filename>.  When you run the <command role="hg-cmd">hg tag</command> command,
   1.119 +Mercurial modifies this file, then automatically commits the change to
   1.120 +it.  This means that every time you run <command role="hg-cmd">hg tag</command>, you'll see a
   1.121 +corresponding changeset in the output of <command role="hg-cmd">hg log</command>.
   1.122 +<!-- &interaction.tag.tip; -->
   1.123 +</para>
   1.124 +
   1.125 +<sect2>
   1.126 +<title>Handling tag conflicts during a merge</title>
   1.127 +
   1.128 +<para>You won't often need to care about the <filename role="special">.hgtags</filename> file, but
   1.129 +it sometimes makes its presence known during a merge.  The format of
   1.130 +the file is simple: it consists of a series of lines.  Each line
   1.131 +starts with a changeset hash, followed by a space, followed by the
   1.132 +name of a tag.
   1.133 +</para>
   1.134 +
   1.135 +<para>If you're resolving a conflict in the <filename role="special">.hgtags</filename> file during
   1.136 +a merge, there's one twist to modifying the <filename role="special">.hgtags</filename> file:
   1.137 +when Mercurial is parsing the tags in a repository, it <emphasis>never</emphasis>
   1.138 +reads the working copy of the <filename role="special">.hgtags</filename> file.  Instead, it
   1.139 +reads the <emphasis>most recently committed</emphasis> revision of the file.
   1.140 +</para>
   1.141 +
   1.142 +<para>An unfortunate consequence of this design is that you can't actually
   1.143 +verify that your merged <filename role="special">.hgtags</filename> file is correct until
   1.144 +<emphasis>after</emphasis> you've committed a change.  So if you find yourself
   1.145 +resolving a conflict on <filename role="special">.hgtags</filename> during a merge, be sure to
   1.146 +run <command role="hg-cmd">hg tags</command> after you commit.  If it finds an error in the
   1.147 +<filename role="special">.hgtags</filename> file, it will report the location of the error,
   1.148 +which you can then fix and commit.  You should then run <command role="hg-cmd">hg tags</command>
   1.149 +again, just to be sure that your fix is correct.
   1.150 +</para>
   1.151 +
   1.152 +</sect2>
   1.153 +<sect2>
   1.154 +<title>Tags and cloning</title>
   1.155 +
   1.156 +<para>You may have noticed that the <command role="hg-cmd">hg clone</command> command has a
   1.157 +<option role="hg-opt-clone">-r</option> option that lets you clone an exact copy of the
   1.158 +repository as of a particular changeset.  The new clone will not
   1.159 +contain any project history that comes after the revision you
   1.160 +specified.  This has an interaction with tags that can surprise the
   1.161 +unwary.
   1.162 +</para>
   1.163 +
   1.164 +<para>Recall that a tag is stored as a revision to the <filename role="special">.hgtags</filename>
   1.165 +file, so that when you create a tag, the changeset in which it's
   1.166 +recorded necessarily refers to an older changeset.  When you run
   1.167 +<command role="hg-cmd">hg clone -r foo</command> to clone a repository as of tag
   1.168 +<literal>foo</literal>, the new clone \emph{will not contain the history that
   1.169 +  created the tag} that you used to clone the repository.  The result
   1.170 +is that you'll get exactly the right subset of the project's history
   1.171 +in the new repository, but <emphasis>not</emphasis> the tag you might have expected.
   1.172 +</para>
   1.173 +
   1.174 +</sect2>
   1.175 +<sect2>
   1.176 +<title>When permanent tags are too much</title>
   1.177 +
   1.178 +<para>Since Mercurial's tags are revision controlled and carried around with
   1.179 +a project's history, everyone you work with will see the tags you
   1.180 +create.  But giving names to revisions has uses beyond simply noting
   1.181 +that revision <literal>4237e45506ee</literal> is really <literal>v2.0.2</literal>.  If
   1.182 +you're trying to track down a subtle bug, you might want a tag to
   1.183 +remind you of something like <quote>Anne saw the symptoms with this
   1.184 +revision</quote>.
   1.185 +</para>
   1.186 +
   1.187 +<para>For cases like this, what you might want to use are <emphasis>local</emphasis> tags.
   1.188 +You can create a local tag with the <option role="hg-opt-tag">-l</option> option to the
   1.189 +<command role="hg-cmd">hg tag</command> command.  This will store the tag in a file called
   1.190 +<filename role="special">.hg/localtags</filename>.  Unlike <filename role="special">.hgtags</filename>,
   1.191 +<filename role="special">.hg/localtags</filename> is not revision controlled.  Any tags you
   1.192 +create using <option role="hg-opt-tag">-l</option> remain strictly local to the repository
   1.193 +you're currently working in.
   1.194 +</para>
   1.195 +
   1.196 +</sect2>
   1.197 +</sect1>
   1.198 +<sect1>
   1.199 +<title>The flow of changes&emdash;big picture vs. little</title>
   1.200 +
   1.201 +<para>To return to the outline I sketched at the beginning of a chapter,
   1.202 +let's think about a project that has multiple concurrent pieces of
   1.203 +work under development at once.
   1.204 +</para>
   1.205 +
   1.206 +<para>There might be a push for a new <quote>main</quote> release; a new minor bugfix
   1.207 +release to the last main release; and an unexpected <quote>hot fix</quote> to an
   1.208 +old release that is now in maintenance mode.
   1.209 +</para>
   1.210 +
   1.211 +<para>The usual way people refer to these different concurrent directions of
   1.212 +development is as <quote>branches</quote>.  However, we've already seen numerous
   1.213 +times that Mercurial treats <emphasis>all of history</emphasis> as a series of
   1.214 +branches and merges.  Really, what we have here is two ideas that are
   1.215 +peripherally related, but which happen to share a name.
   1.216 +</para>
   1.217 +<itemizedlist>
   1.218 +<listitem><para><quote>Big picture</quote> branches represent the sweep of a project's
   1.219 +  evolution; people give them names, and talk about them in
   1.220 +  conversation.
   1.221 +</para>
   1.222 +</listitem>
   1.223 +<listitem><para><quote>Little picture</quote> branches are artefacts of the day-to-day
   1.224 +  activity of developing and merging changes.  They expose the
   1.225 +  narrative of how the code was developed.
   1.226 +</para>
   1.227 +</listitem></itemizedlist>
   1.228 +
   1.229 +</sect1>
   1.230 +<sect1>
   1.231 +<title>Managing big-picture branches in repositories</title>
   1.232 +
   1.233 +<para>The easiest way to isolate a <quote>big picture</quote> branch in Mercurial is in
   1.234 +a dedicated repository.  If you have an existing shared
   1.235 +repository&emdash;let's call it <literal>myproject</literal>&emdash;that reaches a <quote>1.0</quote>
   1.236 +milestone, you can start to prepare for future maintenance releases on
   1.237 +top of version 1.0 by tagging the revision from which you prepared
   1.238 +the 1.0 release.
   1.239 +<!-- &interaction.branch-repo.tag; -->
   1.240 +You can then clone a new shared <literal>myproject-1.0.1</literal> repository as
   1.241 +of that tag.
   1.242 +<!-- &interaction.branch-repo.clone; -->
   1.243 +</para>
   1.244 +
   1.245 +<para>Afterwards, if someone needs to work on a bug fix that ought to go
   1.246 +into an upcoming 1.0.1 minor release, they clone the
   1.247 +<literal>myproject-1.0.1</literal> repository, make their changes, and push them
   1.248 +back.
   1.249 +<!-- &interaction.branch-repo.bugfix; -->
   1.250 +Meanwhile, development for the next major release can continue,
   1.251 +isolated and unabated, in the <literal>myproject</literal> repository.
   1.252 +<!-- &interaction.branch-repo.new; -->
   1.253 +</para>
   1.254 +
   1.255 +</sect1>
   1.256 +<sect1>
   1.257 +<title>Don't repeat yourself: merging across branches</title>
   1.258 +
   1.259 +<para>In many cases, if you have a bug to fix on a maintenance branch, the
   1.260 +chances are good that the bug exists on your project's main branch
   1.261 +(and possibly other maintenance branches, too).  It's a rare developer
   1.262 +who wants to fix the same bug multiple times, so let's look at a few
   1.263 +ways that Mercurial can help you to manage these bugfixes without
   1.264 +duplicating your work.
   1.265 +</para>
   1.266 +
   1.267 +<para>In the simplest instance, all you need to do is pull changes from your
   1.268 +maintenance branch into your local clone of the target branch.
   1.269 +<!-- &interaction.branch-repo.pull; -->
   1.270 +You'll then need to merge the heads of the two branches, and push back
   1.271 +to the main branch.
   1.272 +<!-- &interaction.branch-repo.merge; -->
   1.273 +</para>
   1.274 +
   1.275 +</sect1>
   1.276 +<sect1>
   1.277 +<title>Naming branches within one repository</title>
   1.278 +
   1.279 +<para>In most instances, isolating branches in repositories is the right
   1.280 +approach.  Its simplicity makes it easy to understand; and so it's
   1.281 +hard to make mistakes.  There's a one-to-one relationship between
   1.282 +branches you're working in and directories on your system.  This lets
   1.283 +you use normal (non-Mercurial-aware) tools to work on files within a
   1.284 +branch/repository.
   1.285 +</para>
   1.286 +
   1.287 +<para>If you're more in the <quote>power user</quote> category (<emphasis>and</emphasis> your
   1.288 +collaborators are too), there is an alternative way of handling
   1.289 +branches that you can consider.  I've already mentioned the
   1.290 +human-level distinction between <quote>small picture</quote> and <quote>big picture</quote>
   1.291 +branches.  While Mercurial works with multiple <quote>small picture</quote>
   1.292 +branches in a repository all the time (for example after you pull
   1.293 +changes in, but before you merge them), it can <emphasis>also</emphasis> work with
   1.294 +multiple <quote>big picture</quote> branches.
   1.295 +</para>
   1.296 +
   1.297 +<para>The key to working this way is that Mercurial lets you assign a
   1.298 +persistent <emphasis>name</emphasis> to a branch.  There always exists a branch
   1.299 +named <literal>default</literal>.  Even before you start naming branches
   1.300 +yourself, you can find traces of the <literal>default</literal> branch if you
   1.301 +look for them.
   1.302 +</para>
   1.303 +
   1.304 +<para>As an example, when you run the <command role="hg-cmd">hg commit</command> command, and it pops up
   1.305 +your editor so that you can enter a commit message, look for a line
   1.306 +that contains the text <quote><literal>HG: branch default</literal></quote> at the bottom.
   1.307 +This is telling you that your commit will occur on the branch named
   1.308 +<literal>default</literal>.
   1.309 +</para>
   1.310 +
   1.311 +<para>To start working with named branches, use the <command role="hg-cmd">hg branches</command>
   1.312 +command.  This command lists the named branches already present in
   1.313 +your repository, telling you which changeset is the tip of each.
   1.314 +<!-- &interaction.branch-named.branches; -->
   1.315 +Since you haven't created any named branches yet, the only one that
   1.316 +exists is <literal>default</literal>.
   1.317 +</para>
   1.318 +
   1.319 +<para>To find out what the <quote>current</quote> branch is, run the <command role="hg-cmd">hg branch</command>
   1.320 +command, giving it no arguments.  This tells you what branch the
   1.321 +parent of the current changeset is on.
   1.322 +<!-- &interaction.branch-named.branch; -->
   1.323 +</para>
   1.324 +
   1.325 +<para>To create a new branch, run the <command role="hg-cmd">hg branch</command> command again.  This
   1.326 +time, give it one argument: the name of the branch you want to create.
   1.327 +<!-- &interaction.branch-named.create; -->
   1.328 +</para>
   1.329 +
   1.330 +<para>After you've created a branch, you might wonder what effect the
   1.331 +<command role="hg-cmd">hg branch</command> command has had.  What do the <command role="hg-cmd">hg status</command> and
   1.332 +<command role="hg-cmd">hg tip</command> commands report?
   1.333 +<!-- &interaction.branch-named.status; -->
   1.334 +Nothing has changed in the working directory, and there's been no new
   1.335 +history created.  As this suggests, running the <command role="hg-cmd">hg branch</command> command
   1.336 +has no permanent effect; it only tells Mercurial what branch name to
   1.337 +use the <emphasis>next</emphasis> time you commit a changeset.
   1.338 +</para>
   1.339 +
   1.340 +<para>When you commit a change, Mercurial records the name of the branch on
   1.341 +which you committed.  Once you've switched from the <literal>default</literal>
   1.342 +branch to another and committed, you'll see the name of the new branch
   1.343 +show up in the output of <command role="hg-cmd">hg log</command>, <command role="hg-cmd">hg tip</command>, and other commands
   1.344 +that display the same kind of output.
   1.345 +<!-- &interaction.branch-named.commit; -->
   1.346 +The <command role="hg-cmd">hg log</command>-like commands will print the branch name of every
   1.347 +changeset that's not on the <literal>default</literal> branch.  As a result, if
   1.348 +you never use named branches, you'll never see this information.
   1.349 +</para>
   1.350 +
   1.351 +<para>Once you've named a branch and committed a change with that name,
   1.352 +every subsequent commit that descends from that change will inherit
   1.353 +the same branch name.  You can change the name of a branch at any
   1.354 +time, using the <command role="hg-cmd">hg branch</command> command.
   1.355 +<!-- &interaction.branch-named.rebranch; -->
   1.356 +In practice, this is something you won't do very often, as branch
   1.357 +names tend to have fairly long lifetimes.  (This isn't a rule, just an
   1.358 +observation.)
   1.359 +</para>
   1.360 +
   1.361 +</sect1>
   1.362 +<sect1>
   1.363 +<title>Dealing with multiple named branches in a repository</title>
   1.364 +
   1.365 +<para>If you have more than one named branch in a repository, Mercurial will
   1.366 +remember the branch that your working directory on when you start a
   1.367 +command like <command role="hg-cmd">hg update</command> or <command role="hg-cmd">hg pull -u</command>.  It will update
   1.368 +the working directory to the tip of this branch, no matter what the
   1.369 +<quote>repo-wide</quote> tip is.  To update to a revision that's on a different
   1.370 +named branch, you may need to use the <option role="hg-opt-update">-C</option> option to
   1.371 +<command role="hg-cmd">hg update</command>.
   1.372 +</para>
   1.373 +
   1.374 +<para>This behaviour is a little subtle, so let's see it in action.  First,
   1.375 +let's remind ourselves what branch we're currently on, and what
   1.376 +branches are in our repository.
   1.377 +<!-- &interaction.branch-named.parents; -->
   1.378 +We're on the <literal>bar</literal> branch, but there also exists an older
   1.379 +<command role="hg-cmd">hg foo</command> branch.
   1.380 +</para>
   1.381 +
   1.382 +<para>We can <command role="hg-cmd">hg update</command> back and forth between the tips of the
   1.383 +<literal>foo</literal> and <literal>bar</literal> branches without needing to use the
   1.384 +<option role="hg-opt-update">-C</option> option, because this only involves going backwards
   1.385 +and forwards linearly through our change history.
   1.386 +<!-- &interaction.branch-named.update-switchy; -->
   1.387 +</para>
   1.388 +
   1.389 +<para>If we go back to the <literal>foo</literal> branch and then run <command role="hg-cmd">hg update</command>,
   1.390 +it will keep us on <literal>foo</literal>, not move us to the tip of
   1.391 +<literal>bar</literal>.
   1.392 +<!-- &interaction.branch-named.update-nothing; -->
   1.393 +</para>
   1.394 +
   1.395 +<para>Committing a new change on the <literal>foo</literal> branch introduces a new
   1.396 +head.
   1.397 +<!-- &interaction.branch-named.foo-commit; -->
   1.398 +</para>
   1.399 +
   1.400 +</sect1>
   1.401 +<sect1>
   1.402 +<title>Branch names and merging</title>
   1.403 +
   1.404 +<para>As you've probably noticed, merges in Mercurial are not symmetrical.
   1.405 +Let's say our repository has two heads, 17 and 23.  If I
   1.406 +<command role="hg-cmd">hg update</command> to 17 and then <command role="hg-cmd">hg merge</command> with 23, Mercurial records
   1.407 +17 as the first parent of the merge, and 23 as the second.  Whereas if
   1.408 +I <command role="hg-cmd">hg update</command> to 23 and then <command role="hg-cmd">hg merge</command> with 17, it records 23
   1.409 +as the first parent, and 17 as the second.
   1.410 +</para>
   1.411 +
   1.412 +<para>This affects Mercurial's choice of branch name when you merge.  After
   1.413 +a merge, Mercurial will retain the branch name of the first parent
   1.414 +when you commit the result of the merge.  If your first parent's
   1.415 +branch name is <literal>foo</literal>, and you merge with <literal>bar</literal>, the
   1.416 +branch name will still be <literal>foo</literal> after you merge.
   1.417 +</para>
   1.418 +
   1.419 +<para>It's not unusual for a repository to contain multiple heads, each with
   1.420 +the same branch name.  Let's say I'm working on the <literal>foo</literal>
   1.421 +branch, and so are you.  We commit different changes; I pull your
   1.422 +changes; I now have two heads, each claiming to be on the <literal>foo</literal>
   1.423 +branch.  The result of a merge will be a single head on the
   1.424 +<literal>foo</literal> branch, as you might hope.
   1.425 +</para>
   1.426 +
   1.427 +<para>But if I'm working on the <literal>bar</literal> branch, and I merge work from
   1.428 +the <literal>foo</literal> branch, the result will remain on the <literal>bar</literal>
   1.429 +branch.
   1.430 +<!-- &interaction.branch-named.merge; -->
   1.431 +</para>
   1.432 +
   1.433 +<para>To give a more concrete example, if I'm working on the
   1.434 +<literal>bleeding-edge</literal> branch, and I want to bring in the latest fixes
   1.435 +from the <literal>stable</literal> branch, Mercurial will choose the <quote>right</quote>
   1.436 +(<literal>bleeding-edge</literal>) branch name when I pull and merge from
   1.437 +<literal>stable</literal>.
   1.438 +</para>
   1.439 +
   1.440 +</sect1>
   1.441 +<sect1>
   1.442 +<title>Branch naming is generally useful</title>
   1.443 +
   1.444 +<para>You shouldn't think of named branches as applicable only to situations
   1.445 +where you have multiple long-lived branches cohabiting in a single
   1.446 +repository.  They're very useful even in the one-branch-per-repository
   1.447 +case.
   1.448 +</para>
   1.449 +
   1.450 +<para>In the simplest case, giving a name to each branch gives you a
   1.451 +permanent record of which branch a changeset originated on.  This
   1.452 +gives you more context when you're trying to follow the history of a
   1.453 +long-lived branchy project.
   1.454 +</para>
   1.455 +
   1.456 +<para>If you're working with shared repositories, you can set up a
   1.457 +<literal role="hook">pretxnchangegroup</literal> hook on each that will block incoming changes
   1.458 +that have the <quote>wrong</quote> branch name.  This provides a simple, but
   1.459 +effective, defence against people accidentally pushing changes from a
   1.460 +<quote>bleeding edge</quote> branch to a <quote>stable</quote> branch.  Such a hook might
   1.461 +look like this inside the shared repo's <filename role="special"> /.hgrc</filename>.
   1.462 +</para>
   1.463 +<programlisting>
   1.464 +<para>  [hooks]
   1.465 +  pretxnchangegroup.branch = hg heads --template '{branches} ' | grep mybranch
   1.466 +</para>
   1.467 +</programlisting>
   1.468 +
   1.469 +</sect1>
   1.470 +</chapter>
   1.471 +
   1.472 +<!--
   1.473 +local variables: 
   1.474 +sgml-parent-document: ("00book.xml" "book" "chapter")
   1.475 +end:
   1.476 +-->
   1.477 \ No newline at end of file