| rev |
line source |
|
igor@324
|
1 \chapter{Administración de Versiones y desarrollo ramificado}
|
|
igor@324
|
2 \label{chap:branch}
|
|
igor@324
|
3
|
|
igor@324
|
4 Mercurial ofrece varios mecanismos que le permitirán administrar un
|
|
igor@324
|
5 proyecto que avanza en múltiples frentes simultáneamente. Para
|
|
igor@324
|
6 entender estos mecanismos, demos un vistazo a la estructura usual de
|
|
igor@324
|
7 un proyecto de software.
|
|
igor@324
|
8
|
|
igor@324
|
9 Muchos proyectos de software liberan una versión``mayor'' que contiene
|
|
igor@324
|
10 nuevas características substanciales. En paralelo, pueden liberar
|
|
igor@324
|
11 versiones ``menores''. Estas usualmente son idénticas a las
|
|
igor@324
|
12 versiones mayores en las cuales están basadas, pero con arreglo de
|
|
igor@324
|
13 algunos fallos.
|
|
igor@324
|
14
|
|
igor@324
|
15 En este capítulo, comenzaremos hablando de cómo mantener registro de
|
|
igor@324
|
16 las etapas del proyecto como las liberaciones de una
|
|
igor@324
|
17 versión. Continuaremos hablando del flujo de trabajo entre las
|
|
igor@324
|
18 diferentes fases de un proyecto, y como puede ayudar Mercurial a
|
|
igor@324
|
19 independizar y administrar tal trabajo.
|
|
igor@324
|
20
|
|
igor@324
|
21 \section{Dar un nombre persistente a una revisión}
|
|
igor@324
|
22
|
|
igor@324
|
23 Cuando se decide a otorgar a una revisión el nombre particular de una
|
|
igor@324
|
24 ``versión'', es buena idea grabar la identidad para tal revisión.
|
|
igor@324
|
25 Lo cual permitirá reproducir tal versión en una fecha posterior, o el
|
|
igor@324
|
26 propósito que se considere en ese momento (reproducir un fallo, portar
|
|
igor@324
|
27 a una nueva plataforma, etc).
|
|
igor@324
|
28 \interaction{tag.init}
|
|
igor@324
|
29
|
|
igor@324
|
30 Mercurial le permite dar un nombre permanente a cualquier revisión
|
|
igor@324
|
31 usando la orden \hgcmd{tag}. Sin causa de sorpresa, esos nombres se llaman
|
|
igor@324
|
32 ``tags''(etiquetas).
|
|
igor@324
|
33 \interaction{tag.tag}
|
|
igor@324
|
34
|
|
igor@324
|
35 Un tag no es más que un ``nombre simbólico'' para una revisión. Los
|
|
igor@324
|
36 tags existen únicamente para su conveniencia, dotándolo de una forma
|
|
igor@324
|
37 permanente y sencilla para referirse a una revisión; Mercurial no
|
|
igor@324
|
38 interpreta de ninguna manera los nombres de los tags que usted use.
|
|
igor@324
|
39 Mercurial tampoco impone restricción alguna al nombre de un tag, más
|
|
igor@324
|
40 allá de lo necesario para asegurar que un tag puede parsearse sin
|
|
igor@324
|
41 ambigüedades. El nombre de un tag no puede tener ninguno de los
|
|
igor@324
|
42 caracteres siguientes:
|
|
igor@324
|
43 \begin{itemize}
|
|
igor@324
|
44 \item Dos puntos (ASCII 58, ``\texttt{:}'')
|
|
igor@324
|
45 \item Retroceso (return) (ASCII 13, ``\Verb+\r+'')
|
|
igor@324
|
46 \item Nueva línea (ASCII 10, ``\Verb+\n+'')
|
|
igor@324
|
47 \end{itemize}
|
|
igor@324
|
48
|
|
igor@324
|
49 Puede usar la orden \hgcmd{tags} para observar los tags presentes en
|
|
igor@324
|
50 su repositorio. Al desplegarse, cada revisión marcada se identifica
|
|
igor@324
|
51 primero con su nombre, después el número de revisión y finalmente con
|
|
igor@324
|
52 un hash único de la revisión.
|
|
igor@324
|
53 \interaction{tag.tags}
|
|
igor@324
|
54 Note que \texttt{tip} aparece en la lista de \hgcmd{tags}. El tag
|
|
igor@324
|
55 \texttt{tip} es un tag ``flotante'' especial, que identifica siempre
|
|
igor@324
|
56 la revisión más nueva en el repositorio.
|
|
igor@324
|
57
|
|
igor@324
|
58 Al desplegar la orden \hgcmd{tags}, los tags se listan en orden
|
|
igor@324
|
59 inverso, por número de revisión. Lo que significa usualmente que los
|
|
igor@324
|
60 tags más recientes se listan antes que los más antiguos. También
|
|
igor@324
|
61 significa que el tag \texttt{tip} siempre aparecerá como primer tag
|
|
igor@324
|
62 listado al desplegar la orden \hgcmd{tags}.
|
|
igor@324
|
63
|
|
igor@324
|
64 Cuando ejecuta \hgcmd{log}, se desplegará la revisión que tenga los
|
|
igor@324
|
65 tags asociados a ella, se imprimirán tales tags.
|
|
igor@324
|
66 \interaction{tag.log}
|
|
igor@324
|
67
|
|
igor@324
|
68 Siempre que requiera indicar un ~ID de revisión a una Orden de
|
|
igor@324
|
69 Mercurial, aceptará un nombre de tag en su lugar. Internamente,
|
|
igor@324
|
70 Mercurial traducirá su nombre de tag en el ~ID de revisión
|
|
igor@324
|
71 correspondiente, y lo usará.
|
|
igor@324
|
72 \interaction{tag.log.v1.0}
|
|
igor@324
|
73
|
|
igor@324
|
74 There's no limit on the number of tags you can have in a repository,
|
|
igor@324
|
75 or on the number of tags that a single revision can have. As a
|
|
igor@324
|
76 practical matter, it's not a great idea to have ``too many'' (a number
|
|
igor@324
|
77 which will vary from project to project), simply because tags are
|
|
igor@324
|
78 supposed to help you to find revisions. If you have lots of tags, the
|
|
igor@324
|
79 ease of using them to identify revisions diminishes rapidly.
|
|
igor@324
|
80
|
|
igor@324
|
81 For example, if your project has milestones as frequent as every few
|
|
igor@324
|
82 days, it's perfectly reasonable to tag each one of those. But if you
|
|
igor@324
|
83 have a continuous build system that makes sure every revision can be
|
|
igor@324
|
84 built cleanly, you'd be introducing a lot of noise if you were to tag
|
|
igor@324
|
85 every clean build. Instead, you could tag failed builds (on the
|
|
igor@324
|
86 assumption that they're rare!), or simply not use tags to track
|
|
igor@324
|
87 buildability.
|
|
igor@324
|
88
|
|
igor@324
|
89 If you want to remove a tag that you no longer want, use
|
|
igor@324
|
90 \hgcmdargs{tag}{--remove}.
|
|
igor@324
|
91 \interaction{tag.remove}
|
|
igor@324
|
92 You can also modify a tag at any time, so that it identifies a
|
|
igor@324
|
93 different revision, by simply issuing a new \hgcmd{tag} command.
|
|
igor@324
|
94 You'll have to use the \hgopt{tag}{-f} option to tell Mercurial that
|
|
igor@324
|
95 you \emph{really} want to update the tag.
|
|
igor@324
|
96 \interaction{tag.replace}
|
|
igor@324
|
97 There will still be a permanent record of the previous identity of the
|
|
igor@324
|
98 tag, but Mercurial will no longer use it. There's thus no penalty to
|
|
igor@324
|
99 tagging the wrong revision; all you have to do is turn around and tag
|
|
igor@324
|
100 the correct revision once you discover your error.
|
|
igor@324
|
101
|
|
igor@324
|
102 Mercurial stores tags in a normal revision-controlled file in your
|
|
igor@324
|
103 repository. If you've created any tags, you'll find them in a file
|
|
igor@324
|
104 named \sfilename{.hgtags}. When you run the \hgcmd{tag} command,
|
|
igor@324
|
105 Mercurial modifies this file, then automatically commits the change to
|
|
igor@324
|
106 it. This means that every time you run \hgcmd{tag}, you'll see a
|
|
igor@324
|
107 corresponding changeset in the output of \hgcmd{log}.
|
|
igor@324
|
108 \interaction{tag.tip}
|
|
igor@324
|
109
|
|
igor@324
|
110 \subsection{Handling tag conflicts during a merge}
|
|
igor@324
|
111
|
|
igor@324
|
112 You won't often need to care about the \sfilename{.hgtags} file, but
|
|
igor@324
|
113 it sometimes makes its presence known during a merge. The format of
|
|
igor@324
|
114 the file is simple: it consists of a series of lines. Each line
|
|
igor@324
|
115 starts with a changeset hash, followed by a space, followed by the
|
|
igor@324
|
116 name of a tag.
|
|
igor@324
|
117
|
|
igor@324
|
118 If you're resolving a conflict in the \sfilename{.hgtags} file during
|
|
igor@324
|
119 a merge, there's one twist to modifying the \sfilename{.hgtags} file:
|
|
igor@324
|
120 when Mercurial is parsing the tags in a repository, it \emph{never}
|
|
igor@324
|
121 reads the working copy of the \sfilename{.hgtags} file. Instead, it
|
|
igor@324
|
122 reads the \emph{most recently committed} revision of the file.
|
|
igor@324
|
123
|
|
igor@324
|
124 An unfortunate consequence of this design is that you can't actually
|
|
igor@324
|
125 verify that your merged \sfilename{.hgtags} file is correct until
|
|
igor@324
|
126 \emph{after} you've committed a change. So if you find yourself
|
|
igor@324
|
127 resolving a conflict on \sfilename{.hgtags} during a merge, be sure to
|
|
igor@324
|
128 run \hgcmd{tags} after you commit. If it finds an error in the
|
|
igor@324
|
129 \sfilename{.hgtags} file, it will report the location of the error,
|
|
igor@324
|
130 which you can then fix and commit. You should then run \hgcmd{tags}
|
|
igor@324
|
131 again, just to be sure that your fix is correct.
|
|
igor@324
|
132
|
|
igor@324
|
133 \subsection{Tags and cloning}
|
|
igor@324
|
134
|
|
igor@324
|
135 You may have noticed that the \hgcmd{clone} command has a
|
|
igor@324
|
136 \hgopt{clone}{-r} option that lets you clone an exact copy of the
|
|
igor@324
|
137 repository as of a particular changeset. The new clone will not
|
|
igor@324
|
138 contain any project history that comes after the revision you
|
|
igor@324
|
139 specified. This has an interaction with tags that can surprise the
|
|
igor@324
|
140 unwary.
|
|
igor@324
|
141
|
|
igor@324
|
142 Recall that a tag is stored as a revision to the \sfilename{.hgtags}
|
|
igor@324
|
143 file, so that when you create a tag, the changeset in which it's
|
|
igor@324
|
144 recorded necessarily refers to an older changeset. When you run
|
|
igor@324
|
145 \hgcmdargs{clone}{-r foo} to clone a repository as of tag
|
|
igor@324
|
146 \texttt{foo}, the new clone \emph{will not contain the history that
|
|
igor@324
|
147 created the tag} that you used to clone the repository. The result
|
|
igor@324
|
148 is that you'll get exactly the right subset of the project's history
|
|
igor@324
|
149 in the new repository, but \emph{not} the tag you might have expected.
|
|
igor@324
|
150
|
|
igor@324
|
151 \subsection{When permanent tags are too much}
|
|
igor@324
|
152
|
|
igor@324
|
153 Since Mercurial's tags are revision controlled and carried around with
|
|
igor@324
|
154 a project's history, everyone you work with will see the tags you
|
|
igor@324
|
155 create. But giving names to revisions has uses beyond simply noting
|
|
igor@324
|
156 that revision \texttt{4237e45506ee} is really \texttt{v2.0.2}. If
|
|
igor@324
|
157 you're trying to track down a subtle bug, you might want a tag to
|
|
igor@324
|
158 remind you of something like ``Anne saw the symptoms with this
|
|
igor@324
|
159 revision''.
|
|
igor@324
|
160
|
|
igor@324
|
161 For cases like this, what you might want to use are \emph{local} tags.
|
|
igor@324
|
162 You can create a local tag with the \hgopt{tag}{-l} option to the
|
|
igor@324
|
163 \hgcmd{tag} command. This will store the tag in a file called
|
|
igor@324
|
164 \sfilename{.hg/localtags}. Unlike \sfilename{.hgtags},
|
|
igor@324
|
165 \sfilename{.hg/localtags} is not revision controlled. Any tags you
|
|
igor@324
|
166 create using \hgopt{tag}{-l} remain strictly local to the repository
|
|
igor@324
|
167 you're currently working in.
|
|
igor@324
|
168
|
|
igor@324
|
169 \section{The flow of changes---big picture vs. little}
|
|
igor@324
|
170
|
|
igor@324
|
171 To return to the outline I sketched at the beginning of a chapter,
|
|
igor@324
|
172 let's think about a project that has multiple concurrent pieces of
|
|
igor@324
|
173 work under development at once.
|
|
igor@324
|
174
|
|
igor@324
|
175 There might be a push for a new ``main'' release; a new minor bugfix
|
|
igor@324
|
176 release to the last main release; and an unexpected ``hot fix'' to an
|
|
igor@324
|
177 old release that is now in maintenance mode.
|
|
igor@324
|
178
|
|
igor@324
|
179 The usual way people refer to these different concurrent directions of
|
|
igor@324
|
180 development is as ``branches''. However, we've already seen numerous
|
|
igor@324
|
181 times that Mercurial treats \emph{all of history} as a series of
|
|
igor@324
|
182 branches and merges. Really, what we have here is two ideas that are
|
|
igor@324
|
183 peripherally related, but which happen to share a name.
|
|
igor@324
|
184 \begin{itemize}
|
|
igor@324
|
185 \item ``Big picture'' branches represent the sweep of a project's
|
|
igor@324
|
186 evolution; people give them names, and talk about them in
|
|
igor@324
|
187 conversation.
|
|
igor@324
|
188 \item ``Little picture'' branches are artefacts of the day-to-day
|
|
igor@324
|
189 activity of developing and merging changes. They expose the
|
|
igor@324
|
190 narrative of how the code was developed.
|
|
igor@324
|
191 \end{itemize}
|
|
igor@324
|
192
|
|
igor@324
|
193 \section{Managing big-picture branches in repositories}
|
|
igor@324
|
194
|
|
igor@324
|
195 The easiest way to isolate a ``big picture'' branch in Mercurial is in
|
|
igor@324
|
196 a dedicated repository. If you have an existing shared
|
|
igor@324
|
197 repository---let's call it \texttt{myproject}---that reaches a ``1.0''
|
|
igor@324
|
198 milestone, you can start to prepare for future maintenance releases on
|
|
igor@324
|
199 top of version~1.0 by tagging the revision from which you prepared
|
|
igor@324
|
200 the~1.0 release.
|
|
igor@324
|
201 \interaction{branch-repo.tag}
|
|
igor@324
|
202 You can then clone a new shared \texttt{myproject-1.0.1} repository as
|
|
igor@324
|
203 of that tag.
|
|
igor@324
|
204 \interaction{branch-repo.clone}
|
|
igor@324
|
205
|
|
igor@324
|
206 Afterwards, if someone needs to work on a bug fix that ought to go
|
|
igor@324
|
207 into an upcoming~1.0.1 minor release, they clone the
|
|
igor@324
|
208 \texttt{myproject-1.0.1} repository, make their changes, and push them
|
|
igor@324
|
209 back.
|
|
igor@324
|
210 \interaction{branch-repo.bugfix}
|
|
igor@324
|
211 Meanwhile, development for the next major release can continue,
|
|
igor@324
|
212 isolated and unabated, in the \texttt{myproject} repository.
|
|
igor@324
|
213 \interaction{branch-repo.new}
|
|
igor@324
|
214
|
|
igor@324
|
215 \section{Don't repeat yourself: merging across branches}
|
|
igor@324
|
216
|
|
igor@324
|
217 In many cases, if you have a bug to fix on a maintenance branch, the
|
|
igor@324
|
218 chances are good that the bug exists on your project's main branch
|
|
igor@324
|
219 (and possibly other maintenance branches, too). It's a rare developer
|
|
igor@324
|
220 who wants to fix the same bug multiple times, so let's look at a few
|
|
igor@324
|
221 ways that Mercurial can help you to manage these bugfixes without
|
|
igor@324
|
222 duplicating your work.
|
|
igor@324
|
223
|
|
igor@324
|
224 In the simplest instance, all you need to do is pull changes from your
|
|
igor@324
|
225 maintenance branch into your local clone of the target branch.
|
|
igor@324
|
226 \interaction{branch-repo.pull}
|
|
igor@324
|
227 You'll then need to merge the heads of the two branches, and push back
|
|
igor@324
|
228 to the main branch.
|
|
igor@324
|
229 \interaction{branch-repo.merge}
|
|
igor@324
|
230
|
|
igor@324
|
231 \section{Naming branches within one repository}
|
|
igor@324
|
232
|
|
igor@324
|
233 In most instances, isolating branches in repositories is the right
|
|
igor@324
|
234 approach. Its simplicity makes it easy to understand; and so it's
|
|
igor@324
|
235 hard to make mistakes. There's a one-to-one relationship between
|
|
igor@324
|
236 branches you're working in and directories on your system. This lets
|
|
igor@324
|
237 you use normal (non-Mercurial-aware) tools to work on files within a
|
|
igor@324
|
238 branch/repository.
|
|
igor@324
|
239
|
|
igor@324
|
240 If you're more in the ``power user'' category (\emph{and} your
|
|
igor@324
|
241 collaborators are too), there is an alternative way of handling
|
|
igor@324
|
242 branches that you can consider. I've already mentioned the
|
|
igor@324
|
243 human-level distinction between ``small picture'' and ``big picture''
|
|
igor@324
|
244 branches. While Mercurial works with multiple ``small picture''
|
|
igor@324
|
245 branches in a repository all the time (for example after you pull
|
|
igor@324
|
246 changes in, but before you merge them), it can \emph{also} work with
|
|
igor@324
|
247 multiple ``big picture'' branches.
|
|
igor@324
|
248
|
|
igor@324
|
249 The key to working this way is that Mercurial lets you assign a
|
|
igor@324
|
250 persistent \emph{name} to a branch. There always exists a branch
|
|
igor@324
|
251 named \texttt{default}. Even before you start naming branches
|
|
igor@324
|
252 yourself, you can find traces of the \texttt{default} branch if you
|
|
igor@324
|
253 look for them.
|
|
igor@324
|
254
|
|
igor@324
|
255 As an example, when you run the \hgcmd{commit} command, and it pops up
|
|
igor@324
|
256 your editor so that you can enter a commit message, look for a line
|
|
igor@324
|
257 that contains the text ``\texttt{HG: branch default}'' at the bottom.
|
|
igor@324
|
258 This is telling you that your commit will occur on the branch named
|
|
igor@324
|
259 \texttt{default}.
|
|
igor@324
|
260
|
|
igor@324
|
261 To start working with named branches, use the \hgcmd{branches}
|
|
igor@324
|
262 command. This command lists the named branches already present in
|
|
igor@324
|
263 your repository, telling you which changeset is the tip of each.
|
|
igor@324
|
264 \interaction{branch-named.branches}
|
|
igor@324
|
265 Since you haven't created any named branches yet, the only one that
|
|
igor@324
|
266 exists is \texttt{default}.
|
|
igor@324
|
267
|
|
igor@324
|
268 To find out what the ``current'' branch is, run the \hgcmd{branch}
|
|
igor@324
|
269 command, giving it no arguments. This tells you what branch the
|
|
igor@324
|
270 parent of the current changeset is on.
|
|
igor@324
|
271 \interaction{branch-named.branch}
|
|
igor@324
|
272
|
|
igor@324
|
273 To create a new branch, run the \hgcmd{branch} command again. This
|
|
igor@324
|
274 time, give it one argument: the name of the branch you want to create.
|
|
igor@324
|
275 \interaction{branch-named.create}
|
|
igor@324
|
276
|
|
igor@324
|
277 After you've created a branch, you might wonder what effect the
|
|
igor@324
|
278 \hgcmd{branch} command has had. What do the \hgcmd{status} and
|
|
igor@324
|
279 \hgcmd{tip} commands report?
|
|
igor@324
|
280 \interaction{branch-named.status}
|
|
igor@324
|
281 Nothing has changed in the working directory, and there's been no new
|
|
igor@324
|
282 history created. As this suggests, running the \hgcmd{branch} command
|
|
igor@324
|
283 has no permanent effect; it only tells Mercurial what branch name to
|
|
igor@324
|
284 use the \emph{next} time you commit a changeset.
|
|
igor@324
|
285
|
|
igor@324
|
286 When you commit a change, Mercurial records the name of the branch on
|
|
igor@324
|
287 which you committed. Once you've switched from the \texttt{default}
|
|
igor@324
|
288 branch to another and committed, you'll see the name of the new branch
|
|
igor@324
|
289 show up in the output of \hgcmd{log}, \hgcmd{tip}, and other commands
|
|
igor@324
|
290 that display the same kind of output.
|
|
igor@324
|
291 \interaction{branch-named.commit}
|
|
igor@324
|
292 The \hgcmd{log}-like commands will print the branch name of every
|
|
igor@324
|
293 changeset that's not on the \texttt{default} branch. As a result, if
|
|
igor@324
|
294 you never use named branches, you'll never see this information.
|
|
igor@324
|
295
|
|
igor@324
|
296 Once you've named a branch and committed a change with that name,
|
|
igor@324
|
297 every subsequent commit that descends from that change will inherit
|
|
igor@324
|
298 the same branch name. You can change the name of a branch at any
|
|
igor@324
|
299 time, using the \hgcmd{branch} command.
|
|
igor@324
|
300 \interaction{branch-named.rebranch}
|
|
igor@324
|
301 In practice, this is something you won't do very often, as branch
|
|
igor@324
|
302 names tend to have fairly long lifetimes. (This isn't a rule, just an
|
|
igor@324
|
303 observation.)
|
|
igor@324
|
304
|
|
igor@324
|
305 \section{Dealing with multiple named branches in a repository}
|
|
igor@324
|
306
|
|
igor@324
|
307 If you have more than one named branch in a repository, Mercurial will
|
|
igor@324
|
308 remember the branch that your working directory on when you start a
|
|
igor@324
|
309 command like \hgcmd{update} or \hgcmdargs{pull}{-u}. It will update
|
|
igor@324
|
310 the working directory to the tip of this branch, no matter what the
|
|
igor@324
|
311 ``repo-wide'' tip is. To update to a revision that's on a different
|
|
igor@324
|
312 named branch, you may need to use the \hgopt{update}{-C} option to
|
|
igor@324
|
313 \hgcmd{update}.
|
|
igor@324
|
314
|
|
igor@324
|
315 This behaviour is a little subtle, so let's see it in action. First,
|
|
igor@324
|
316 let's remind ourselves what branch we're currently on, and what
|
|
igor@324
|
317 branches are in our repository.
|
|
igor@324
|
318 \interaction{branch-named.parents}
|
|
igor@324
|
319 We're on the \texttt{bar} branch, but there also exists an older
|
|
igor@324
|
320 \hgcmd{foo} branch.
|
|
igor@324
|
321
|
|
igor@324
|
322 We can \hgcmd{update} back and forth between the tips of the
|
|
igor@324
|
323 \texttt{foo} and \texttt{bar} branches without needing to use the
|
|
igor@324
|
324 \hgopt{update}{-C} option, because this only involves going backwards
|
|
igor@324
|
325 and forwards linearly through our change history.
|
|
igor@324
|
326 \interaction{branch-named.update-switchy}
|
|
igor@324
|
327
|
|
igor@324
|
328 If we go back to the \texttt{foo} branch and then run \hgcmd{update},
|
|
igor@324
|
329 it will keep us on \texttt{foo}, not move us to the tip of
|
|
igor@324
|
330 \texttt{bar}.
|
|
igor@324
|
331 \interaction{branch-named.update-nothing}
|
|
igor@324
|
332
|
|
igor@324
|
333 Committing a new change on the \texttt{foo} branch introduces a new
|
|
igor@324
|
334 head.
|
|
igor@324
|
335 \interaction{branch-named.foo-commit}
|
|
igor@324
|
336
|
|
igor@324
|
337 \section{Branch names and merging}
|
|
igor@324
|
338
|
|
igor@324
|
339 As you've probably noticed, merges in Mercurial are not symmetrical.
|
|
igor@324
|
340 Let's say our repository has two heads, 17 and 23. If I
|
|
igor@324
|
341 \hgcmd{update} to 17 and then \hgcmd{merge} with 23, Mercurial records
|
|
igor@324
|
342 17 as the first parent of the merge, and 23 as the second. Whereas if
|
|
igor@324
|
343 I \hgcmd{update} to 23 and then \hgcmd{merge} with 17, it records 23
|
|
igor@324
|
344 as the first parent, and 17 as the second.
|
|
igor@324
|
345
|
|
igor@324
|
346 This affects Mercurial's choice of branch name when you merge. After
|
|
igor@324
|
347 a merge, Mercurial will retain the branch name of the first parent
|
|
igor@324
|
348 when you commit the result of the merge. If your first parent's
|
|
igor@324
|
349 branch name is \texttt{foo}, and you merge with \texttt{bar}, the
|
|
igor@324
|
350 branch name will still be \texttt{foo} after you merge.
|
|
igor@324
|
351
|
|
igor@324
|
352 It's not unusual for a repository to contain multiple heads, each with
|
|
igor@324
|
353 the same branch name. Let's say I'm working on the \texttt{foo}
|
|
igor@324
|
354 branch, and so are you. We commit different changes; I pull your
|
|
igor@324
|
355 changes; I now have two heads, each claiming to be on the \texttt{foo}
|
|
igor@324
|
356 branch. The result of a merge will be a single head on the
|
|
igor@324
|
357 \texttt{foo} branch, as you might hope.
|
|
igor@324
|
358
|
|
igor@324
|
359 But if I'm working on the \texttt{bar} branch, and I merge work from
|
|
igor@324
|
360 the \texttt{foo} branch, the result will remain on the \texttt{bar}
|
|
igor@324
|
361 branch.
|
|
igor@324
|
362 \interaction{branch-named.merge}
|
|
igor@324
|
363
|
|
igor@324
|
364 To give a more concrete example, if I'm working on the
|
|
igor@324
|
365 \texttt{bleeding-edge} branch, and I want to bring in the latest fixes
|
|
igor@324
|
366 from the \texttt{stable} branch, Mercurial will choose the ``right''
|
|
igor@324
|
367 (\texttt{bleeding-edge}) branch name when I pull and merge from
|
|
igor@324
|
368 \texttt{stable}.
|
|
igor@324
|
369
|
|
igor@324
|
370 \section{Branch naming is generally useful}
|
|
igor@324
|
371
|
|
igor@324
|
372 You shouldn't think of named branches as applicable only to situations
|
|
igor@324
|
373 where you have multiple long-lived branches cohabiting in a single
|
|
igor@324
|
374 repository. They're very useful even in the one-branch-per-repository
|
|
igor@324
|
375 case.
|
|
igor@324
|
376
|
|
igor@324
|
377 In the simplest case, giving a name to each branch gives you a
|
|
igor@324
|
378 permanent record of which branch a changeset originated on. This
|
|
igor@324
|
379 gives you more context when you're trying to follow the history of a
|
|
igor@324
|
380 long-lived branchy project.
|
|
igor@324
|
381
|
|
igor@324
|
382 If you're working with shared repositories, you can set up a
|
|
igor@324
|
383 \hook{pretxnchangegroup} hook on each that will block incoming changes
|
|
igor@324
|
384 that have the ``wrong'' branch name. This provides a simple, but
|
|
igor@324
|
385 effective, defence against people accidentally pushing changes from a
|
|
igor@324
|
386 ``bleeding edge'' branch to a ``stable'' branch. Such a hook might
|
|
igor@324
|
387 look like this inside the shared repo's \hgrc.
|
|
igor@324
|
388 \begin{codesample2}
|
|
igor@324
|
389 [hooks]
|
|
igor@324
|
390 pretxnchangegroup.branch = hg heads --template '{branches} ' | grep mybranch
|
|
igor@324
|
391 \end{codesample2}
|
|
igor@324
|
392
|
|
igor@324
|
393 %%% Local Variables:
|
|
igor@324
|
394 %%% mode: latex
|
|
igor@324
|
395 %%% TeX-master: "00book"
|
|
igor@324
|
396 %%% End:
|
