hgbook
diff en/branch.tex @ 196:4237e45506ee
Add early material describing tags.
author | Bryan O'Sullivan <bos@serpentine.com> |
---|---|
date | Mon Apr 16 16:11:24 2007 -0700 (2007-04-16) |
parents | b60e2de6dbc3 |
children | 76697ae503db |
line diff
1.1 --- a/en/branch.tex Mon Apr 16 14:19:31 2007 -0700 1.2 +++ b/en/branch.tex Mon Apr 16 16:11:24 2007 -0700 1.3 @@ -1,7 +1,122 @@ 1.4 -\chapter{Managing branchy development} 1.5 +\chapter{Managing releases and branchy development} 1.6 \label{chap:branch} 1.7 1.8 +Mercurial provides two ways for you to manage a project that is making 1.9 +progress on multiple fronts at once. To understand these mechanisms, 1.10 +let's first take a look at a fairly normal software project structure. 1.11 1.12 +Many software projects issue periodic ``major'' releases that contain 1.13 +substantial new features. In parallel, they may issue ``minor'' 1.14 +releases. These are usually identical to the major releases off which 1.15 +they're based, but with a few bugs fixed. 1.16 + 1.17 +\section{Giving a persistent name to a revision} 1.18 + 1.19 +Once you decide that you'd like to call a particular revision a 1.20 +``release'', it's a good idea to record the identity of that revision. 1.21 +This will let you reproduce that release at a later date, for whatever 1.22 +purpose you might need at the time (reproducing a bug, porting to a 1.23 +new platform, etc). 1.24 +\interaction{tag.init} 1.25 + 1.26 +Mercurial lets you give a permanent name to any revision using the 1.27 +\hgcmd{tag} command. Not surprisingly, these names are called 1.28 +``tags''. 1.29 +\interaction{tag.tag} 1.30 + 1.31 +A tag is nothing more than a ``symbolic name'' for a revision. Tags 1.32 +exist purely for your convenience, so that you have a handy permanent 1.33 +way to refer to a revision; Mercurial doesn't interpret the tag names 1.34 +you use in any way. Neither does Mercurial place any restrictions on 1.35 +the name of a tag, beyond a few that are necessary to ensure that a 1.36 +tag can be parsed unambiguously. A tag name cannot contain any of the 1.37 +following characters: 1.38 +\begin{itemize} 1.39 +\item Colon (ASCII 58, ``\texttt{:}'') 1.40 +\item Carriage return (ASCII 13, ``\texttt{$\backslash$r}'') 1.41 +\item Newline (ASCII 10, ``\texttt{$\backslash$n}'') 1.42 +\end{itemize} 1.43 + 1.44 +You can use the \hgcmd{tags} command to display the tags present in 1.45 +your repository. In the output, each tagged revision is identified 1.46 +first by its name, then by revision number, and finally by the unique 1.47 +hash of the revision. 1.48 +\interaction{tag.tags} 1.49 +Notice that \texttt{tip} is listed in the output of \hgcmd{tags}. The 1.50 +\texttt{tip} tag is a special ``floating'' tag, which always 1.51 +identifies the newest revision in the repository. 1.52 + 1.53 +In the output of the \hgcmd{tags} command, tags are listed in reverse 1.54 +order, by revision number. This usually means that recent tags are 1.55 +listed before older tags. It also means that \texttt{tip} is always 1.56 +going to be the first tag listed in the output of \hgcmd{tags}. 1.57 + 1.58 +When you run \hgcmd{log}, if it displays a revision that has tags 1.59 +associated with it, it will print those tags. 1.60 +\interaction{tag.log} 1.61 + 1.62 +Any time you need to provide a revision~ID to a Mercurial command, the 1.63 +command will accept a tag name in its place. Internally, Mercurial 1.64 +will translate your tag name into the corresponding revision~ID, then 1.65 +use that. 1.66 +\interaction{tag.log.v1.0} 1.67 + 1.68 +There's no limit on the number of tags you can have in a repository, 1.69 +or on the number of tags that a single revision can have. As a 1.70 +practical matter, it's not a great idea to have ``too many'' (a number 1.71 +which will vary from project to project), simply because tags are 1.72 +supposed to help you to find revisions. If you have lots of tags, the 1.73 +ease of using them to identify revisions diminishes rapidly. 1.74 + 1.75 +For example, if your project has milestones as frequent as every few 1.76 +days, it's perfectly reasonable to tag each one of those. But if you 1.77 +have a continuous build system that makes sure every revision can be 1.78 +built cleanly, you'd be introducing a lot of noise if you were to tag 1.79 +every clean build. Instead, you could tag failed builds (on the 1.80 +assumption that they're rare!), or simply not use tags to track 1.81 +buildability. 1.82 + 1.83 +If you want to remove a tag that you no longer want, use 1.84 +\hgcmdargs{tag}{--remove}. 1.85 +\interaction{tag.remove} 1.86 +You can also modify a tag at any time, so that it identifies a 1.87 +different revision, by simply issuing a new \hgcmd{tag} command. 1.88 +You'll have to use the \hgopt{tag}{-f} option to tell Mercurial that 1.89 +you \emph{really} want to update the tag. 1.90 +\interaction{tag.replace} 1.91 +There will still be a permanent record of the previous identity of the 1.92 +tag, but Mercurial will no longer use it. 1.93 + 1.94 +Mercurial stores tags in a normal revision-controlled file in your 1.95 +repository. If you've created any tags, you'll find them in a file 1.96 +named \sfilename{.hgtags}. When you run the \hgcmd{tag} command, 1.97 +Mercurial modifies this file, then automatically commits the change to 1.98 +it. This means that every time you run \hgcmd{tag}, you'll see a 1.99 +corresponding changeset in the output of \hgcmd{log}. 1.100 +\interaction{tag.tip} 1.101 + 1.102 +\subsection{Handling tag conflicts during a merge} 1.103 + 1.104 +You won't often need to care about the \sfilename{.hgtags} file, but 1.105 +it sometimes makes its presence known during a merge. The format of 1.106 +the file is simple: it consists of a series of lines. Each line 1.107 +starts with a changeset hash, followed by a space, followed by the 1.108 +name of a tag. 1.109 + 1.110 +If you're resolving a conflict in the \sfilename{.hgtags} file during 1.111 +a merge, there's one twist to modifying the \sfilename{.hgtags} file: 1.112 +when Mercurial is parsing the tags in a repository, it \emph{never} 1.113 +reads the working copy of the \sfilename{.hgtags} file. Instead, it 1.114 +reads the \emph{most recently committed} revision of the file. 1.115 + 1.116 +An unfortunate consequence of this design is that you can't actually 1.117 +verify that your merged \sfilename{.hgtags} file is correct until 1.118 +\emph{after} you've committed a change. So if you find yourself 1.119 +resolving a conflict on \sfilename{.hgtags} during a merge, be sure to 1.120 +run \hgcmd{tags} after you commit. If it finds an error in the 1.121 +\sfilename{.hgtags} file, it will report the location of the error, 1.122 +which you can then fix and commit. You should then run \hgcmd{tags} 1.123 +again, just to be sure that your fix is correct. 1.124 1.125 %%% Local Variables: 1.126 %%% mode: latex