| rev |
line source |
|
bos@196
|
1 \chapter{Managing releases and branchy development}
|
|
bos@187
|
2 \label{chap:branch}
|
|
bos@187
|
3
|
|
bos@196
|
4 Mercurial provides two ways for you to manage a project that is making
|
|
bos@196
|
5 progress on multiple fronts at once. To understand these mechanisms,
|
|
bos@196
|
6 let's first take a look at a fairly normal software project structure.
|
|
bos@187
|
7
|
|
bos@196
|
8 Many software projects issue periodic ``major'' releases that contain
|
|
bos@196
|
9 substantial new features. In parallel, they may issue ``minor''
|
|
bos@196
|
10 releases. These are usually identical to the major releases off which
|
|
bos@196
|
11 they're based, but with a few bugs fixed.
|
|
bos@196
|
12
|
|
bos@196
|
13 \section{Giving a persistent name to a revision}
|
|
bos@196
|
14
|
|
bos@196
|
15 Once you decide that you'd like to call a particular revision a
|
|
bos@196
|
16 ``release'', it's a good idea to record the identity of that revision.
|
|
bos@196
|
17 This will let you reproduce that release at a later date, for whatever
|
|
bos@196
|
18 purpose you might need at the time (reproducing a bug, porting to a
|
|
bos@196
|
19 new platform, etc).
|
|
bos@196
|
20 \interaction{tag.init}
|
|
bos@196
|
21
|
|
bos@196
|
22 Mercurial lets you give a permanent name to any revision using the
|
|
bos@196
|
23 \hgcmd{tag} command. Not surprisingly, these names are called
|
|
bos@196
|
24 ``tags''.
|
|
bos@196
|
25 \interaction{tag.tag}
|
|
bos@196
|
26
|
|
bos@196
|
27 A tag is nothing more than a ``symbolic name'' for a revision. Tags
|
|
bos@196
|
28 exist purely for your convenience, so that you have a handy permanent
|
|
bos@196
|
29 way to refer to a revision; Mercurial doesn't interpret the tag names
|
|
bos@196
|
30 you use in any way. Neither does Mercurial place any restrictions on
|
|
bos@196
|
31 the name of a tag, beyond a few that are necessary to ensure that a
|
|
bos@196
|
32 tag can be parsed unambiguously. A tag name cannot contain any of the
|
|
bos@196
|
33 following characters:
|
|
bos@196
|
34 \begin{itemize}
|
|
bos@196
|
35 \item Colon (ASCII 58, ``\texttt{:}'')
|
|
bos@196
|
36 \item Carriage return (ASCII 13, ``\texttt{$\backslash$r}'')
|
|
bos@196
|
37 \item Newline (ASCII 10, ``\texttt{$\backslash$n}'')
|
|
bos@196
|
38 \end{itemize}
|
|
bos@196
|
39
|
|
bos@196
|
40 You can use the \hgcmd{tags} command to display the tags present in
|
|
bos@196
|
41 your repository. In the output, each tagged revision is identified
|
|
bos@196
|
42 first by its name, then by revision number, and finally by the unique
|
|
bos@196
|
43 hash of the revision.
|
|
bos@196
|
44 \interaction{tag.tags}
|
|
bos@196
|
45 Notice that \texttt{tip} is listed in the output of \hgcmd{tags}. The
|
|
bos@196
|
46 \texttt{tip} tag is a special ``floating'' tag, which always
|
|
bos@196
|
47 identifies the newest revision in the repository.
|
|
bos@196
|
48
|
|
bos@196
|
49 In the output of the \hgcmd{tags} command, tags are listed in reverse
|
|
bos@196
|
50 order, by revision number. This usually means that recent tags are
|
|
bos@196
|
51 listed before older tags. It also means that \texttt{tip} is always
|
|
bos@196
|
52 going to be the first tag listed in the output of \hgcmd{tags}.
|
|
bos@196
|
53
|
|
bos@196
|
54 When you run \hgcmd{log}, if it displays a revision that has tags
|
|
bos@196
|
55 associated with it, it will print those tags.
|
|
bos@196
|
56 \interaction{tag.log}
|
|
bos@196
|
57
|
|
bos@196
|
58 Any time you need to provide a revision~ID to a Mercurial command, the
|
|
bos@196
|
59 command will accept a tag name in its place. Internally, Mercurial
|
|
bos@196
|
60 will translate your tag name into the corresponding revision~ID, then
|
|
bos@196
|
61 use that.
|
|
bos@196
|
62 \interaction{tag.log.v1.0}
|
|
bos@196
|
63
|
|
bos@196
|
64 There's no limit on the number of tags you can have in a repository,
|
|
bos@196
|
65 or on the number of tags that a single revision can have. As a
|
|
bos@196
|
66 practical matter, it's not a great idea to have ``too many'' (a number
|
|
bos@196
|
67 which will vary from project to project), simply because tags are
|
|
bos@196
|
68 supposed to help you to find revisions. If you have lots of tags, the
|
|
bos@196
|
69 ease of using them to identify revisions diminishes rapidly.
|
|
bos@196
|
70
|
|
bos@196
|
71 For example, if your project has milestones as frequent as every few
|
|
bos@196
|
72 days, it's perfectly reasonable to tag each one of those. But if you
|
|
bos@196
|
73 have a continuous build system that makes sure every revision can be
|
|
bos@196
|
74 built cleanly, you'd be introducing a lot of noise if you were to tag
|
|
bos@196
|
75 every clean build. Instead, you could tag failed builds (on the
|
|
bos@196
|
76 assumption that they're rare!), or simply not use tags to track
|
|
bos@196
|
77 buildability.
|
|
bos@196
|
78
|
|
bos@196
|
79 If you want to remove a tag that you no longer want, use
|
|
bos@196
|
80 \hgcmdargs{tag}{--remove}.
|
|
bos@196
|
81 \interaction{tag.remove}
|
|
bos@196
|
82 You can also modify a tag at any time, so that it identifies a
|
|
bos@196
|
83 different revision, by simply issuing a new \hgcmd{tag} command.
|
|
bos@196
|
84 You'll have to use the \hgopt{tag}{-f} option to tell Mercurial that
|
|
bos@196
|
85 you \emph{really} want to update the tag.
|
|
bos@196
|
86 \interaction{tag.replace}
|
|
bos@196
|
87 There will still be a permanent record of the previous identity of the
|
|
bos@196
|
88 tag, but Mercurial will no longer use it.
|
|
bos@196
|
89
|
|
bos@196
|
90 Mercurial stores tags in a normal revision-controlled file in your
|
|
bos@196
|
91 repository. If you've created any tags, you'll find them in a file
|
|
bos@196
|
92 named \sfilename{.hgtags}. When you run the \hgcmd{tag} command,
|
|
bos@196
|
93 Mercurial modifies this file, then automatically commits the change to
|
|
bos@196
|
94 it. This means that every time you run \hgcmd{tag}, you'll see a
|
|
bos@196
|
95 corresponding changeset in the output of \hgcmd{log}.
|
|
bos@196
|
96 \interaction{tag.tip}
|
|
bos@196
|
97
|
|
bos@196
|
98 \subsection{Handling tag conflicts during a merge}
|
|
bos@196
|
99
|
|
bos@196
|
100 You won't often need to care about the \sfilename{.hgtags} file, but
|
|
bos@196
|
101 it sometimes makes its presence known during a merge. The format of
|
|
bos@196
|
102 the file is simple: it consists of a series of lines. Each line
|
|
bos@196
|
103 starts with a changeset hash, followed by a space, followed by the
|
|
bos@196
|
104 name of a tag.
|
|
bos@196
|
105
|
|
bos@196
|
106 If you're resolving a conflict in the \sfilename{.hgtags} file during
|
|
bos@196
|
107 a merge, there's one twist to modifying the \sfilename{.hgtags} file:
|
|
bos@196
|
108 when Mercurial is parsing the tags in a repository, it \emph{never}
|
|
bos@196
|
109 reads the working copy of the \sfilename{.hgtags} file. Instead, it
|
|
bos@196
|
110 reads the \emph{most recently committed} revision of the file.
|
|
bos@196
|
111
|
|
bos@196
|
112 An unfortunate consequence of this design is that you can't actually
|
|
bos@196
|
113 verify that your merged \sfilename{.hgtags} file is correct until
|
|
bos@196
|
114 \emph{after} you've committed a change. So if you find yourself
|
|
bos@196
|
115 resolving a conflict on \sfilename{.hgtags} during a merge, be sure to
|
|
bos@196
|
116 run \hgcmd{tags} after you commit. If it finds an error in the
|
|
bos@196
|
117 \sfilename{.hgtags} file, it will report the location of the error,
|
|
bos@196
|
118 which you can then fix and commit. You should then run \hgcmd{tags}
|
|
bos@196
|
119 again, just to be sure that your fix is correct.
|
|
bos@187
|
120
|
|
bos@187
|
121 %%% Local Variables:
|
|
bos@187
|
122 %%% mode: latex
|
|
bos@187
|
123 %%% TeX-master: "00book"
|
|
bos@187
|
124 %%% End:
|
