| 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@196
|
42 \item Carriage return (ASCII 13, ``\texttt{$\backslash$r}'')
|
|
bos@196
|
43 \item Newline (ASCII 10, ``\texttt{$\backslash$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
|
|
bos@198
|
132 \hgopt{clone}{-r} option that lets you clone an exact copy of
|
|
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@187
|
227 %%% Local Variables:
|
|
bos@187
|
228 %%% mode: latex
|
|
bos@187
|
229 %%% TeX-master: "00book"
|
|
bos@187
|
230 %%% End:
|
