1.1 --- a/en/Makefile	Mon Apr 16 14:43:23 2007 -0700
     1.2 +++ b/en/Makefile	Mon Apr 16 16:11:24 2007 -0700
     1.3 @@ -75,6 +75,7 @@
     1.4  	mq.tutorial \
     1.5  	rename.divergent \
     1.6  	rollback \
     1.7 +	tag \
     1.8  	template.simple \
     1.9  	template.svnstyle \
    1.10  	tour \

     2.1 --- a/en/branch.tex	Mon Apr 16 14:43:23 2007 -0700
     2.2 +++ b/en/branch.tex	Mon Apr 16 16:11:24 2007 -0700
     2.3 @@ -1,7 +1,122 @@
     2.4 -\chapter{Managing branchy development}
     2.5 +\chapter{Managing releases and branchy development}
     2.6  \label{chap:branch}
     2.7  
     2.8 +Mercurial provides two ways for you to manage a project that is making
     2.9 +progress on multiple fronts at once.  To understand these mechanisms,
    2.10 +let's first take a look at a fairly normal software project structure.
    2.11  
    2.12 +Many software projects issue periodic ``major'' releases that contain
    2.13 +substantial new features.  In parallel, they may issue ``minor''
    2.14 +releases.  These are usually identical to the major releases off which
    2.15 +they're based, but with a few bugs fixed.
    2.16 +
    2.17 +\section{Giving a persistent name to a revision}
    2.18 +
    2.19 +Once you decide that you'd like to call a particular revision a
    2.20 +``release'', it's a good idea to record the identity of that revision.
    2.21 +This will let you reproduce that release at a later date, for whatever
    2.22 +purpose you might need at the time (reproducing a bug, porting to a
    2.23 +new platform, etc).
    2.24 +\interaction{tag.init}
    2.25 +
    2.26 +Mercurial lets you give a permanent name to any revision using the
    2.27 +\hgcmd{tag} command.  Not surprisingly, these names are called
    2.28 +``tags''.
    2.29 +\interaction{tag.tag}
    2.30 +
    2.31 +A tag is nothing more than a ``symbolic name'' for a revision.  Tags
    2.32 +exist purely for your convenience, so that you have a handy permanent
    2.33 +way to refer to a revision; Mercurial doesn't interpret the tag names
    2.34 +you use in any way.  Neither does Mercurial place any restrictions on
    2.35 +the name of a tag, beyond a few that are necessary to ensure that a
    2.36 +tag can be parsed unambiguously.  A tag name cannot contain any of the
    2.37 +following characters:
    2.38 +\begin{itemize}
    2.39 +\item Colon (ASCII 58, ``\texttt{:}'')
    2.40 +\item Carriage return (ASCII 13, ``\texttt{$\backslash$r}'')
    2.41 +\item Newline (ASCII 10, ``\texttt{$\backslash$n}'')
    2.42 +\end{itemize}
    2.43 +
    2.44 +You can use the \hgcmd{tags} command to display the tags present in
    2.45 +your repository.  In the output, each tagged revision is identified
    2.46 +first by its name, then by revision number, and finally by the unique
    2.47 +hash of the revision.  
    2.48 +\interaction{tag.tags}
    2.49 +Notice that \texttt{tip} is listed in the output of \hgcmd{tags}.  The
    2.50 +\texttt{tip} tag is a special ``floating'' tag, which always
    2.51 +identifies the newest revision in the repository.
    2.52 +
    2.53 +In the output of the \hgcmd{tags} command, tags are listed in reverse
    2.54 +order, by revision number.  This usually means that recent tags are
    2.55 +listed before older tags.  It also means that \texttt{tip} is always
    2.56 +going to be the first tag listed in the output of \hgcmd{tags}.
    2.57 +
    2.58 +When you run \hgcmd{log}, if it displays a revision that has tags
    2.59 +associated with it, it will print those tags.
    2.60 +\interaction{tag.log}
    2.61 +
    2.62 +Any time you need to provide a revision~ID to a Mercurial command, the
    2.63 +command will accept a tag name in its place.  Internally, Mercurial
    2.64 +will translate your tag name into the corresponding revision~ID, then
    2.65 +use that.
    2.66 +\interaction{tag.log.v1.0}
    2.67 +
    2.68 +There's no limit on the number of tags you can have in a repository,
    2.69 +or on the number of tags that a single revision can have.  As a
    2.70 +practical matter, it's not a great idea to have ``too many'' (a number
    2.71 +which will vary from project to project), simply because tags are
    2.72 +supposed to help you to find revisions.  If you have lots of tags, the
    2.73 +ease of using them to identify revisions diminishes rapidly.
    2.74 +
    2.75 +For example, if your project has milestones as frequent as every few
    2.76 +days, it's perfectly reasonable to tag each one of those.  But if you
    2.77 +have a continuous build system that makes sure every revision can be
    2.78 +built cleanly, you'd be introducing a lot of noise if you were to tag
    2.79 +every clean build.  Instead, you could tag failed builds (on the
    2.80 +assumption that they're rare!), or simply not use tags to track
    2.81 +buildability.
    2.82 +
    2.83 +If you want to remove a tag that you no longer want, use
    2.84 +\hgcmdargs{tag}{--remove}.  
    2.85 +\interaction{tag.remove}
    2.86 +You can also modify a tag at any time, so that it identifies a
    2.87 +different revision, by simply issuing a new \hgcmd{tag} command.
    2.88 +You'll have to use the \hgopt{tag}{-f} option to tell Mercurial that
    2.89 +you \emph{really} want to update the tag.
    2.90 +\interaction{tag.replace}
    2.91 +There will still be a permanent record of the previous identity of the
    2.92 +tag, but Mercurial will no longer use it.
    2.93 +
    2.94 +Mercurial stores tags in a normal revision-controlled file in your
    2.95 +repository.  If you've created any tags, you'll find them in a file
    2.96 +named \sfilename{.hgtags}.  When you run the \hgcmd{tag} command,
    2.97 +Mercurial modifies this file, then automatically commits the change to
    2.98 +it.  This means that every time you run \hgcmd{tag}, you'll see a
    2.99 +corresponding changeset in the output of \hgcmd{log}.
   2.100 +\interaction{tag.tip}
   2.101 +
   2.102 +\subsection{Handling tag conflicts during a merge}
   2.103 +
   2.104 +You won't often need to care about the \sfilename{.hgtags} file, but
   2.105 +it sometimes makes its presence known during a merge.  The format of
   2.106 +the file is simple: it consists of a series of lines.  Each line
   2.107 +starts with a changeset hash, followed by a space, followed by the
   2.108 +name of a tag.
   2.109 +
   2.110 +If you're resolving a conflict in the \sfilename{.hgtags} file during
   2.111 +a merge, there's one twist to modifying the \sfilename{.hgtags} file:
   2.112 +when Mercurial is parsing the tags in a repository, it \emph{never}
   2.113 +reads the working copy of the \sfilename{.hgtags} file.  Instead, it
   2.114 +reads the \emph{most recently committed} revision of the file.
   2.115 +
   2.116 +An unfortunate consequence of this design is that you can't actually
   2.117 +verify that your merged \sfilename{.hgtags} file is correct until
   2.118 +\emph{after} you've committed a change.  So if you find yourself
   2.119 +resolving a conflict on \sfilename{.hgtags} during a merge, be sure to
   2.120 +run \hgcmd{tags} after you commit.  If it finds an error in the
   2.121 +\sfilename{.hgtags} file, it will report the location of the error,
   2.122 +which you can then fix and commit.  You should then run \hgcmd{tags}
   2.123 +again, just to be sure that your fix is correct.
   2.124  
   2.125  %%% Local Variables: 
   2.126  %%% mode: latex

     3.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     3.2 +++ b/en/examples/tag	Mon Apr 16 16:11:24 2007 -0700
     3.3 @@ -0,0 +1,44 @@
     3.4 +#!/bin/bash
     3.5 +
     3.6 +#$ name: init
     3.7 +
     3.8 +hg init mytag
     3.9 +cd mytag
    3.10 +
    3.11 +echo hello > myfile
    3.12 +hg commit -A -m 'Initial commit'
    3.13 +
    3.14 +#$ name: tag
    3.15 +
    3.16 +hg tag v1.0
    3.17 +
    3.18 +#$ name: tags
    3.19 +
    3.20 +hg tags
    3.21 +
    3.22 +#$ name: log
    3.23 +
    3.24 +hg log
    3.25 +
    3.26 +#$ name: log.v1.0
    3.27 +
    3.28 +echo goodbye > myfile2
    3.29 +hg commit -A -m 'Second commit'
    3.30 +hg log -r v1.0
    3.31 +
    3.32 +#$ name: remove
    3.33 +
    3.34 +hg tag --remove v1.0
    3.35 +hg tags
    3.36 +
    3.37 +#$ name: replace
    3.38 +
    3.39 +hg tag -r 1 v1.1
    3.40 +hg tags
    3.41 +hg tag -r 2 v1.1
    3.42 +hg tag -f -r 2 v1.1
    3.43 +hg tags
    3.44 +
    3.45 +#$ name: tip
    3.46 +
    3.47 +hg tip

     4.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     4.2 +++ b/en/examples/tag.init.out	Mon Apr 16 16:11:24 2007 -0700
     4.3 @@ -0,0 +1,5 @@
     4.4 +$ \textbf{hg init mytag}
     4.5 +$ \textbf{cd mytag}
     4.6 +$ \textbf{echo hello > myfile}
     4.7 +$ \textbf{hg commit -A -m 'Initial commit'}
     4.8 +adding myfile

     5.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     5.2 +++ b/en/examples/tag.log.out	Mon Apr 16 16:11:24 2007 -0700
     5.3 @@ -0,0 +1,13 @@
     5.4 +$ \textbf{hg log}
     5.5 +changeset:   
     5.6 +tag:         tip
     5.7 +user:        Bryan O'Sullivan <bos@serpentine.com>
     5.8 +
     5.9 +summary:     Added tag v1.0 for changeset 
    5.10 +
    5.11 +changeset:   
    5.12 +tag:         v1.0
    5.13 +user:        Bryan O'Sullivan <bos@serpentine.com>
    5.14 +
    5.15 +summary:     Initial commit
    5.16 +

     6.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     6.2 +++ b/en/examples/tag.log.v1.0.out	Mon Apr 16 16:11:24 2007 -0700
     6.3 @@ -0,0 +1,10 @@
     6.4 +$ \textbf{echo goodbye > myfile2}
     6.5 +$ \textbf{hg commit -A -m 'Second commit'}
     6.6 +adding myfile2
     6.7 +$ \textbf{hg log -r v1.0}
     6.8 +changeset:   
     6.9 +tag:         v1.0
    6.10 +user:        Bryan O'Sullivan <bos@serpentine.com>
    6.11 +
    6.12 +summary:     Initial commit
    6.13 +

     7.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     7.2 +++ b/en/examples/tag.remove.out	Mon Apr 16 16:11:24 2007 -0700
     7.3 @@ -0,0 +1,3 @@
     7.4 +$ \textbf{hg tag --remove v1.0}
     7.5 +$ \textbf{hg tags}
     7.6 +tip                                

     8.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     8.2 +++ b/en/examples/tag.replace.out	Mon Apr 16 16:11:24 2007 -0700
     8.3 @@ -0,0 +1,10 @@
     8.4 +$ \textbf{hg tag -r 1 v1.1}
     8.5 +$ \textbf{hg tags}
     8.6 +tip                                
     8.7 +v1.1                               
     8.8 +$ \textbf{hg tag -r 2 v1.1}
     8.9 +abort: a tag named v1.1 already exists (use -f to force)
    8.10 +$ \textbf{hg tag -f -r 2 v1.1}
    8.11 +$ \textbf{hg tags}
    8.12 +tip                                
    8.13 +v1.1                               

     9.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     9.2 +++ b/en/examples/tag.tag.out	Mon Apr 16 16:11:24 2007 -0700
     9.3 @@ -0,0 +1,1 @@
     9.4 +$ \textbf{hg tag v1.0}

    10.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
    10.2 +++ b/en/examples/tag.tags.out	Mon Apr 16 16:11:24 2007 -0700
    10.3 @@ -0,0 +1,3 @@
    10.4 +$ \textbf{hg tags}
    10.5 +tip                                
    10.6 +v1.0                               

    11.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
    11.2 +++ b/en/examples/tag.tip.out	Mon Apr 16 16:11:24 2007 -0700
    11.3 @@ -0,0 +1,7 @@
    11.4 +$ \textbf{hg tip}
    11.5 +changeset:   
    11.6 +tag:         tip
    11.7 +user:        Bryan O'Sullivan <bos@serpentine.com>
    11.8 +
    11.9 +summary:     Added tag v1.1 for changeset 
   11.10 +