hgbook
diff es/branch.tex @ 324:1afa6cce993d
Starting to translate branch chapter
author | Igor TAmara <igor@tamarapatino.org> |
---|---|
date | Fri Oct 17 05:42:54 2008 -0500 (2008-10-17) |
parents | |
children | 8bedea2b8d60 |
line diff
1.1 --- /dev/null Thu Jan 01 00:00:00 1970 +0000 1.2 +++ b/es/branch.tex Fri Oct 17 05:42:54 2008 -0500 1.3 @@ -0,0 +1,396 @@ 1.4 +\chapter{Administración de Versiones y desarrollo ramificado} 1.5 +\label{chap:branch} 1.6 + 1.7 +Mercurial ofrece varios mecanismos que le permitirán administrar un 1.8 +proyecto que avanza en múltiples frentes simultáneamente. Para 1.9 +entender estos mecanismos, demos un vistazo a la estructura usual de 1.10 +un proyecto de software. 1.11 + 1.12 +Muchos proyectos de software liberan una versión``mayor'' que contiene 1.13 +nuevas características substanciales. En paralelo, pueden liberar 1.14 +versiones ``menores''. Estas usualmente son idénticas a las 1.15 +versiones mayores en las cuales están basadas, pero con arreglo de 1.16 +algunos fallos. 1.17 + 1.18 +En este capítulo, comenzaremos hablando de cómo mantener registro de 1.19 +las etapas del proyecto como las liberaciones de una 1.20 +versión. Continuaremos hablando del flujo de trabajo entre las 1.21 +diferentes fases de un proyecto, y como puede ayudar Mercurial a 1.22 +independizar y administrar tal trabajo. 1.23 + 1.24 +\section{Dar un nombre persistente a una revisión} 1.25 + 1.26 +Cuando se decide a otorgar a una revisión el nombre particular de una 1.27 +``versión'', es buena idea grabar la identidad para tal revisión. 1.28 +Lo cual permitirá reproducir tal versión en una fecha posterior, o el 1.29 +propósito que se considere en ese momento (reproducir un fallo, portar 1.30 +a una nueva plataforma, etc). 1.31 +\interaction{tag.init} 1.32 + 1.33 +Mercurial le permite dar un nombre permanente a cualquier revisión 1.34 +usando la orden \hgcmd{tag}. Sin causa de sorpresa, esos nombres se llaman 1.35 +``tags''(etiquetas). 1.36 +\interaction{tag.tag} 1.37 + 1.38 +Un tag no es más que un ``nombre simbólico'' para una revisión. Los 1.39 +tags existen únicamente para su conveniencia, dotándolo de una forma 1.40 +permanente y sencilla para referirse a una revisión; Mercurial no 1.41 +interpreta de ninguna manera los nombres de los tags que usted use. 1.42 +Mercurial tampoco impone restricción alguna al nombre de un tag, más 1.43 +allá de lo necesario para asegurar que un tag puede parsearse sin 1.44 +ambigüedades. El nombre de un tag no puede tener ninguno de los 1.45 +caracteres siguientes: 1.46 +\begin{itemize} 1.47 +\item Dos puntos (ASCII 58, ``\texttt{:}'') 1.48 +\item Retroceso (return) (ASCII 13, ``\Verb+\r+'') 1.49 +\item Nueva línea (ASCII 10, ``\Verb+\n+'') 1.50 +\end{itemize} 1.51 + 1.52 +Puede usar la orden \hgcmd{tags} para observar los tags presentes en 1.53 +su repositorio. Al desplegarse, cada revisión marcada se identifica 1.54 +primero con su nombre, después el número de revisión y finalmente con 1.55 +un hash único de la revisión. 1.56 +\interaction{tag.tags} 1.57 +Note que \texttt{tip} aparece en la lista de \hgcmd{tags}. El tag 1.58 +\texttt{tip} es un tag ``flotante'' especial, que identifica siempre 1.59 +la revisión más nueva en el repositorio. 1.60 + 1.61 +Al desplegar la orden \hgcmd{tags}, los tags se listan en orden 1.62 +inverso, por número de revisión. Lo que significa usualmente que los 1.63 +tags más recientes se listan antes que los más antiguos. También 1.64 +significa que el tag \texttt{tip} siempre aparecerá como primer tag 1.65 +listado al desplegar la orden \hgcmd{tags}. 1.66 + 1.67 +Cuando ejecuta \hgcmd{log}, se desplegará la revisión que tenga los 1.68 +tags asociados a ella, se imprimirán tales tags. 1.69 +\interaction{tag.log} 1.70 + 1.71 +Siempre que requiera indicar un ~ID de revisión a una Orden de 1.72 +Mercurial, aceptará un nombre de tag en su lugar. Internamente, 1.73 +Mercurial traducirá su nombre de tag en el ~ID de revisión 1.74 +correspondiente, y lo usará. 1.75 +\interaction{tag.log.v1.0} 1.76 + 1.77 +There's no limit on the number of tags you can have in a repository, 1.78 +or on the number of tags that a single revision can have. As a 1.79 +practical matter, it's not a great idea to have ``too many'' (a number 1.80 +which will vary from project to project), simply because tags are 1.81 +supposed to help you to find revisions. If you have lots of tags, the 1.82 +ease of using them to identify revisions diminishes rapidly. 1.83 + 1.84 +For example, if your project has milestones as frequent as every few 1.85 +days, it's perfectly reasonable to tag each one of those. But if you 1.86 +have a continuous build system that makes sure every revision can be 1.87 +built cleanly, you'd be introducing a lot of noise if you were to tag 1.88 +every clean build. Instead, you could tag failed builds (on the 1.89 +assumption that they're rare!), or simply not use tags to track 1.90 +buildability. 1.91 + 1.92 +If you want to remove a tag that you no longer want, use 1.93 +\hgcmdargs{tag}{--remove}. 1.94 +\interaction{tag.remove} 1.95 +You can also modify a tag at any time, so that it identifies a 1.96 +different revision, by simply issuing a new \hgcmd{tag} command. 1.97 +You'll have to use the \hgopt{tag}{-f} option to tell Mercurial that 1.98 +you \emph{really} want to update the tag. 1.99 +\interaction{tag.replace} 1.100 +There will still be a permanent record of the previous identity of the 1.101 +tag, but Mercurial will no longer use it. There's thus no penalty to 1.102 +tagging the wrong revision; all you have to do is turn around and tag 1.103 +the correct revision once you discover your error. 1.104 + 1.105 +Mercurial stores tags in a normal revision-controlled file in your 1.106 +repository. If you've created any tags, you'll find them in a file 1.107 +named \sfilename{.hgtags}. When you run the \hgcmd{tag} command, 1.108 +Mercurial modifies this file, then automatically commits the change to 1.109 +it. This means that every time you run \hgcmd{tag}, you'll see a 1.110 +corresponding changeset in the output of \hgcmd{log}. 1.111 +\interaction{tag.tip} 1.112 + 1.113 +\subsection{Handling tag conflicts during a merge} 1.114 + 1.115 +You won't often need to care about the \sfilename{.hgtags} file, but 1.116 +it sometimes makes its presence known during a merge. The format of 1.117 +the file is simple: it consists of a series of lines. Each line 1.118 +starts with a changeset hash, followed by a space, followed by the 1.119 +name of a tag. 1.120 + 1.121 +If you're resolving a conflict in the \sfilename{.hgtags} file during 1.122 +a merge, there's one twist to modifying the \sfilename{.hgtags} file: 1.123 +when Mercurial is parsing the tags in a repository, it \emph{never} 1.124 +reads the working copy of the \sfilename{.hgtags} file. Instead, it 1.125 +reads the \emph{most recently committed} revision of the file. 1.126 + 1.127 +An unfortunate consequence of this design is that you can't actually 1.128 +verify that your merged \sfilename{.hgtags} file is correct until 1.129 +\emph{after} you've committed a change. So if you find yourself 1.130 +resolving a conflict on \sfilename{.hgtags} during a merge, be sure to 1.131 +run \hgcmd{tags} after you commit. If it finds an error in the 1.132 +\sfilename{.hgtags} file, it will report the location of the error, 1.133 +which you can then fix and commit. You should then run \hgcmd{tags} 1.134 +again, just to be sure that your fix is correct. 1.135 + 1.136 +\subsection{Tags and cloning} 1.137 + 1.138 +You may have noticed that the \hgcmd{clone} command has a 1.139 +\hgopt{clone}{-r} option that lets you clone an exact copy of the 1.140 +repository as of a particular changeset. The new clone will not 1.141 +contain any project history that comes after the revision you 1.142 +specified. This has an interaction with tags that can surprise the 1.143 +unwary. 1.144 + 1.145 +Recall that a tag is stored as a revision to the \sfilename{.hgtags} 1.146 +file, so that when you create a tag, the changeset in which it's 1.147 +recorded necessarily refers to an older changeset. When you run 1.148 +\hgcmdargs{clone}{-r foo} to clone a repository as of tag 1.149 +\texttt{foo}, the new clone \emph{will not contain the history that 1.150 + created the tag} that you used to clone the repository. The result 1.151 +is that you'll get exactly the right subset of the project's history 1.152 +in the new repository, but \emph{not} the tag you might have expected. 1.153 + 1.154 +\subsection{When permanent tags are too much} 1.155 + 1.156 +Since Mercurial's tags are revision controlled and carried around with 1.157 +a project's history, everyone you work with will see the tags you 1.158 +create. But giving names to revisions has uses beyond simply noting 1.159 +that revision \texttt{4237e45506ee} is really \texttt{v2.0.2}. If 1.160 +you're trying to track down a subtle bug, you might want a tag to 1.161 +remind you of something like ``Anne saw the symptoms with this 1.162 +revision''. 1.163 + 1.164 +For cases like this, what you might want to use are \emph{local} tags. 1.165 +You can create a local tag with the \hgopt{tag}{-l} option to the 1.166 +\hgcmd{tag} command. This will store the tag in a file called 1.167 +\sfilename{.hg/localtags}. Unlike \sfilename{.hgtags}, 1.168 +\sfilename{.hg/localtags} is not revision controlled. Any tags you 1.169 +create using \hgopt{tag}{-l} remain strictly local to the repository 1.170 +you're currently working in. 1.171 + 1.172 +\section{The flow of changes---big picture vs. little} 1.173 + 1.174 +To return to the outline I sketched at the beginning of a chapter, 1.175 +let's think about a project that has multiple concurrent pieces of 1.176 +work under development at once. 1.177 + 1.178 +There might be a push for a new ``main'' release; a new minor bugfix 1.179 +release to the last main release; and an unexpected ``hot fix'' to an 1.180 +old release that is now in maintenance mode. 1.181 + 1.182 +The usual way people refer to these different concurrent directions of 1.183 +development is as ``branches''. However, we've already seen numerous 1.184 +times that Mercurial treats \emph{all of history} as a series of 1.185 +branches and merges. Really, what we have here is two ideas that are 1.186 +peripherally related, but which happen to share a name. 1.187 +\begin{itemize} 1.188 +\item ``Big picture'' branches represent the sweep of a project's 1.189 + evolution; people give them names, and talk about them in 1.190 + conversation. 1.191 +\item ``Little picture'' branches are artefacts of the day-to-day 1.192 + activity of developing and merging changes. They expose the 1.193 + narrative of how the code was developed. 1.194 +\end{itemize} 1.195 + 1.196 +\section{Managing big-picture branches in repositories} 1.197 + 1.198 +The easiest way to isolate a ``big picture'' branch in Mercurial is in 1.199 +a dedicated repository. If you have an existing shared 1.200 +repository---let's call it \texttt{myproject}---that reaches a ``1.0'' 1.201 +milestone, you can start to prepare for future maintenance releases on 1.202 +top of version~1.0 by tagging the revision from which you prepared 1.203 +the~1.0 release. 1.204 +\interaction{branch-repo.tag} 1.205 +You can then clone a new shared \texttt{myproject-1.0.1} repository as 1.206 +of that tag. 1.207 +\interaction{branch-repo.clone} 1.208 + 1.209 +Afterwards, if someone needs to work on a bug fix that ought to go 1.210 +into an upcoming~1.0.1 minor release, they clone the 1.211 +\texttt{myproject-1.0.1} repository, make their changes, and push them 1.212 +back. 1.213 +\interaction{branch-repo.bugfix} 1.214 +Meanwhile, development for the next major release can continue, 1.215 +isolated and unabated, in the \texttt{myproject} repository. 1.216 +\interaction{branch-repo.new} 1.217 + 1.218 +\section{Don't repeat yourself: merging across branches} 1.219 + 1.220 +In many cases, if you have a bug to fix on a maintenance branch, the 1.221 +chances are good that the bug exists on your project's main branch 1.222 +(and possibly other maintenance branches, too). It's a rare developer 1.223 +who wants to fix the same bug multiple times, so let's look at a few 1.224 +ways that Mercurial can help you to manage these bugfixes without 1.225 +duplicating your work. 1.226 + 1.227 +In the simplest instance, all you need to do is pull changes from your 1.228 +maintenance branch into your local clone of the target branch. 1.229 +\interaction{branch-repo.pull} 1.230 +You'll then need to merge the heads of the two branches, and push back 1.231 +to the main branch. 1.232 +\interaction{branch-repo.merge} 1.233 + 1.234 +\section{Naming branches within one repository} 1.235 + 1.236 +In most instances, isolating branches in repositories is the right 1.237 +approach. Its simplicity makes it easy to understand; and so it's 1.238 +hard to make mistakes. There's a one-to-one relationship between 1.239 +branches you're working in and directories on your system. This lets 1.240 +you use normal (non-Mercurial-aware) tools to work on files within a 1.241 +branch/repository. 1.242 + 1.243 +If you're more in the ``power user'' category (\emph{and} your 1.244 +collaborators are too), there is an alternative way of handling 1.245 +branches that you can consider. I've already mentioned the 1.246 +human-level distinction between ``small picture'' and ``big picture'' 1.247 +branches. While Mercurial works with multiple ``small picture'' 1.248 +branches in a repository all the time (for example after you pull 1.249 +changes in, but before you merge them), it can \emph{also} work with 1.250 +multiple ``big picture'' branches. 1.251 + 1.252 +The key to working this way is that Mercurial lets you assign a 1.253 +persistent \emph{name} to a branch. There always exists a branch 1.254 +named \texttt{default}. Even before you start naming branches 1.255 +yourself, you can find traces of the \texttt{default} branch if you 1.256 +look for them. 1.257 + 1.258 +As an example, when you run the \hgcmd{commit} command, and it pops up 1.259 +your editor so that you can enter a commit message, look for a line 1.260 +that contains the text ``\texttt{HG: branch default}'' at the bottom. 1.261 +This is telling you that your commit will occur on the branch named 1.262 +\texttt{default}. 1.263 + 1.264 +To start working with named branches, use the \hgcmd{branches} 1.265 +command. This command lists the named branches already present in 1.266 +your repository, telling you which changeset is the tip of each. 1.267 +\interaction{branch-named.branches} 1.268 +Since you haven't created any named branches yet, the only one that 1.269 +exists is \texttt{default}. 1.270 + 1.271 +To find out what the ``current'' branch is, run the \hgcmd{branch} 1.272 +command, giving it no arguments. This tells you what branch the 1.273 +parent of the current changeset is on. 1.274 +\interaction{branch-named.branch} 1.275 + 1.276 +To create a new branch, run the \hgcmd{branch} command again. This 1.277 +time, give it one argument: the name of the branch you want to create. 1.278 +\interaction{branch-named.create} 1.279 + 1.280 +After you've created a branch, you might wonder what effect the 1.281 +\hgcmd{branch} command has had. What do the \hgcmd{status} and 1.282 +\hgcmd{tip} commands report? 1.283 +\interaction{branch-named.status} 1.284 +Nothing has changed in the working directory, and there's been no new 1.285 +history created. As this suggests, running the \hgcmd{branch} command 1.286 +has no permanent effect; it only tells Mercurial what branch name to 1.287 +use the \emph{next} time you commit a changeset. 1.288 + 1.289 +When you commit a change, Mercurial records the name of the branch on 1.290 +which you committed. Once you've switched from the \texttt{default} 1.291 +branch to another and committed, you'll see the name of the new branch 1.292 +show up in the output of \hgcmd{log}, \hgcmd{tip}, and other commands 1.293 +that display the same kind of output. 1.294 +\interaction{branch-named.commit} 1.295 +The \hgcmd{log}-like commands will print the branch name of every 1.296 +changeset that's not on the \texttt{default} branch. As a result, if 1.297 +you never use named branches, you'll never see this information. 1.298 + 1.299 +Once you've named a branch and committed a change with that name, 1.300 +every subsequent commit that descends from that change will inherit 1.301 +the same branch name. You can change the name of a branch at any 1.302 +time, using the \hgcmd{branch} command. 1.303 +\interaction{branch-named.rebranch} 1.304 +In practice, this is something you won't do very often, as branch 1.305 +names tend to have fairly long lifetimes. (This isn't a rule, just an 1.306 +observation.) 1.307 + 1.308 +\section{Dealing with multiple named branches in a repository} 1.309 + 1.310 +If you have more than one named branch in a repository, Mercurial will 1.311 +remember the branch that your working directory on when you start a 1.312 +command like \hgcmd{update} or \hgcmdargs{pull}{-u}. It will update 1.313 +the working directory to the tip of this branch, no matter what the 1.314 +``repo-wide'' tip is. To update to a revision that's on a different 1.315 +named branch, you may need to use the \hgopt{update}{-C} option to 1.316 +\hgcmd{update}. 1.317 + 1.318 +This behaviour is a little subtle, so let's see it in action. First, 1.319 +let's remind ourselves what branch we're currently on, and what 1.320 +branches are in our repository. 1.321 +\interaction{branch-named.parents} 1.322 +We're on the \texttt{bar} branch, but there also exists an older 1.323 +\hgcmd{foo} branch. 1.324 + 1.325 +We can \hgcmd{update} back and forth between the tips of the 1.326 +\texttt{foo} and \texttt{bar} branches without needing to use the 1.327 +\hgopt{update}{-C} option, because this only involves going backwards 1.328 +and forwards linearly through our change history. 1.329 +\interaction{branch-named.update-switchy} 1.330 + 1.331 +If we go back to the \texttt{foo} branch and then run \hgcmd{update}, 1.332 +it will keep us on \texttt{foo}, not move us to the tip of 1.333 +\texttt{bar}. 1.334 +\interaction{branch-named.update-nothing} 1.335 + 1.336 +Committing a new change on the \texttt{foo} branch introduces a new 1.337 +head. 1.338 +\interaction{branch-named.foo-commit} 1.339 + 1.340 +\section{Branch names and merging} 1.341 + 1.342 +As you've probably noticed, merges in Mercurial are not symmetrical. 1.343 +Let's say our repository has two heads, 17 and 23. If I 1.344 +\hgcmd{update} to 17 and then \hgcmd{merge} with 23, Mercurial records 1.345 +17 as the first parent of the merge, and 23 as the second. Whereas if 1.346 +I \hgcmd{update} to 23 and then \hgcmd{merge} with 17, it records 23 1.347 +as the first parent, and 17 as the second. 1.348 + 1.349 +This affects Mercurial's choice of branch name when you merge. After 1.350 +a merge, Mercurial will retain the branch name of the first parent 1.351 +when you commit the result of the merge. If your first parent's 1.352 +branch name is \texttt{foo}, and you merge with \texttt{bar}, the 1.353 +branch name will still be \texttt{foo} after you merge. 1.354 + 1.355 +It's not unusual for a repository to contain multiple heads, each with 1.356 +the same branch name. Let's say I'm working on the \texttt{foo} 1.357 +branch, and so are you. We commit different changes; I pull your 1.358 +changes; I now have two heads, each claiming to be on the \texttt{foo} 1.359 +branch. The result of a merge will be a single head on the 1.360 +\texttt{foo} branch, as you might hope. 1.361 + 1.362 +But if I'm working on the \texttt{bar} branch, and I merge work from 1.363 +the \texttt{foo} branch, the result will remain on the \texttt{bar} 1.364 +branch. 1.365 +\interaction{branch-named.merge} 1.366 + 1.367 +To give a more concrete example, if I'm working on the 1.368 +\texttt{bleeding-edge} branch, and I want to bring in the latest fixes 1.369 +from the \texttt{stable} branch, Mercurial will choose the ``right'' 1.370 +(\texttt{bleeding-edge}) branch name when I pull and merge from 1.371 +\texttt{stable}. 1.372 + 1.373 +\section{Branch naming is generally useful} 1.374 + 1.375 +You shouldn't think of named branches as applicable only to situations 1.376 +where you have multiple long-lived branches cohabiting in a single 1.377 +repository. They're very useful even in the one-branch-per-repository 1.378 +case. 1.379 + 1.380 +In the simplest case, giving a name to each branch gives you a 1.381 +permanent record of which branch a changeset originated on. This 1.382 +gives you more context when you're trying to follow the history of a 1.383 +long-lived branchy project. 1.384 + 1.385 +If you're working with shared repositories, you can set up a 1.386 +\hook{pretxnchangegroup} hook on each that will block incoming changes 1.387 +that have the ``wrong'' branch name. This provides a simple, but 1.388 +effective, defence against people accidentally pushing changes from a 1.389 +``bleeding edge'' branch to a ``stable'' branch. Such a hook might 1.390 +look like this inside the shared repo's \hgrc. 1.391 +\begin{codesample2} 1.392 + [hooks] 1.393 + pretxnchangegroup.branch = hg heads --template '{branches} ' | grep mybranch 1.394 +\end{codesample2} 1.395 + 1.396 +%%% Local Variables: 1.397 +%%% mode: latex 1.398 +%%% TeX-master: "00book" 1.399 +%%% End: