1.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     1.2 +++ b/es/99book.bib	Fri Oct 17 05:42:54 2008 -0500
     1.3 @@ -0,0 +1,1 @@
     1.4 +../en/99book.bib
     1.5 \ No newline at end of file

     2.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     2.2 +++ b/es/99defs.tex	Fri Oct 17 05:42:54 2008 -0500
     2.3 @@ -0,0 +1,1 @@
     2.4 +../en/99defs.tex
     2.5 \ No newline at end of file

     3.1 --- a/es/Leame.1st	Fri Oct 17 04:21:35 2008 -0500
     3.2 +++ b/es/Leame.1st	Fri Oct 17 05:42:54 2008 -0500
     3.3 @@ -12,7 +12,26 @@
     3.4  En esta sección indicamos quienes están traduciendo
     3.5  y quienes revisando lo traducido. Coloque su nombre 
     3.6  para que los demás colaboradores sepan en dónde 
     3.7 -enfocar sus esfuerzos.
     3.8 +enfocar sus esfuerzos.  En este momento estamos dejando 
     3.9 +que *make* nos guíe.
    3.10 +
    3.11 +== Traducción ==
    3.12 + branch.tex : Igor Támara
    3.13 +Su elección aquí
    3.14 +
    3.15 +== Revisión ==
    3.16 +Su elección aquí
    3.17 +
    3.18 += Unificación de Términos de Traducción =
    3.19 +Por favor mantenga esta lista en orden alfabético
    3.20 +
    3.21 + Branch: Rama
    3.22 + Bug: Fallo
    3.23 + Command: Orden
    3.24 + Milestone: Etapa
    3.25 + Release: Versión o liberación de versión
    3.26  
    3.27  = Traductores =
    3.28 +Por favor mantenga esta lista en orden alfabético
    3.29   * Igor Támara <igor@tamarapatino.org>
    3.30 + * Su nombre <su@e.mail>
    3.31 \ No newline at end of file

     4.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     4.2 +++ b/es/branch.tex	Fri Oct 17 05:42:54 2008 -0500
     4.3 @@ -0,0 +1,396 @@
     4.4 +\chapter{Administración de Versiones y desarrollo ramificado}
     4.5 +\label{chap:branch}
     4.6 +
     4.7 +Mercurial ofrece varios mecanismos que le permitirán administrar un
     4.8 +proyecto que avanza en múltiples frentes simultáneamente. Para
     4.9 +entender estos mecanismos, demos un vistazo a la estructura usual de
    4.10 +un proyecto de software.
    4.11 +
    4.12 +Muchos proyectos de software liberan una versión``mayor'' que contiene
    4.13 +nuevas características substanciales.  En paralelo, pueden liberar
    4.14 +versiones ``menores''.   Estas usualmente son idénticas a las
    4.15 +versiones mayores en las cuales están basadas, pero con arreglo de
    4.16 +algunos fallos.
    4.17 +
    4.18 +En este capítulo, comenzaremos hablando de cómo mantener registro de
    4.19 +las etapas del proyecto como las liberaciones de una
    4.20 +versión. Continuaremos hablando del flujo de trabajo entre las
    4.21 +diferentes fases de un proyecto, y como puede ayudar Mercurial a
    4.22 +independizar y administrar tal trabajo.
    4.23 +
    4.24 +\section{Dar un nombre persistente a una revisión}
    4.25 +
    4.26 +Cuando se decide a otorgar a una revisión el nombre particular de una
    4.27 +``versión'', es buena idea grabar la identidad para tal revisión.
    4.28 +Lo cual permitirá reproducir tal versión en una fecha posterior, o el
    4.29 +propósito que se considere en ese momento (reproducir un fallo, portar
    4.30 +a una nueva plataforma, etc).
    4.31 +\interaction{tag.init}
    4.32 +
    4.33 +Mercurial le permite dar un nombre permanente a cualquier revisión
    4.34 +usando la orden \hgcmd{tag}.  Sin causa de sorpresa, esos nombres se llaman
    4.35 +``tags''(etiquetas).
    4.36 +\interaction{tag.tag}
    4.37 +
    4.38 +Un tag no es más que un ``nombre simbólico'' para una revisión.  Los
    4.39 +tags existen únicamente para su conveniencia, dotándolo de una forma
    4.40 +permanente y sencilla para referirse a una revisión; Mercurial no
    4.41 +interpreta de ninguna manera los nombres de los tags que usted use.
    4.42 +Mercurial tampoco impone restricción alguna al nombre de un tag, más
    4.43 +allá de lo necesario para asegurar que un tag puede parsearse sin
    4.44 +ambigüedades. El nombre de un tag no puede tener ninguno de los
    4.45 +caracteres siguientes:
    4.46 +\begin{itemize}
    4.47 +\item Dos puntos (ASCII 58, ``\texttt{:}'')
    4.48 +\item Retroceso (return) (ASCII 13, ``\Verb+\r+'')
    4.49 +\item Nueva línea (ASCII 10, ``\Verb+\n+'')
    4.50 +\end{itemize}
    4.51 +
    4.52 +Puede usar la orden \hgcmd{tags} para observar los tags presentes en
    4.53 +su repositorio. Al desplegarse, cada revisión marcada se identifica
    4.54 +primero con su nombre, después el número de revisión y finalmente con
    4.55 +un hash único de la revisión.
    4.56 +\interaction{tag.tags}
    4.57 +Note que \texttt{tip} aparece en la lista de \hgcmd{tags}.  El tag
    4.58 +\texttt{tip} es un tag ``flotante'' especial, que identifica siempre
    4.59 +la revisión más nueva en el repositorio.
    4.60 +
    4.61 +Al desplegar la orden \hgcmd{tags}, los tags se listan en orden
    4.62 +inverso, por número de revisión. Lo que significa usualmente que los
    4.63 +tags más recientes se listan antes que los más antiguos. También
    4.64 +significa que el tag \texttt{tip} siempre aparecerá como primer tag
    4.65 +listado al desplegar la orden \hgcmd{tags}.
    4.66 +
    4.67 +Cuando ejecuta \hgcmd{log}, se desplegará la revisión que tenga los
    4.68 +tags asociados a ella, se imprimirán tales tags.
    4.69 +\interaction{tag.log}
    4.70 +
    4.71 +Siempre que requiera indicar un ~ID de revisión a una Orden de
    4.72 +Mercurial, aceptará un nombre de tag en su lugar.  Internamente,
    4.73 +Mercurial traducirá su nombre de tag en el ~ID de revisión
    4.74 +correspondiente, y lo usará.
    4.75 +\interaction{tag.log.v1.0}
    4.76 +
    4.77 +There's no limit on the number of tags you can have in a repository,
    4.78 +or on the number of tags that a single revision can have.  As a
    4.79 +practical matter, it's not a great idea to have ``too many'' (a number
    4.80 +which will vary from project to project), simply because tags are
    4.81 +supposed to help you to find revisions.  If you have lots of tags, the
    4.82 +ease of using them to identify revisions diminishes rapidly.
    4.83 +
    4.84 +For example, if your project has milestones as frequent as every few
    4.85 +days, it's perfectly reasonable to tag each one of those.  But if you
    4.86 +have a continuous build system that makes sure every revision can be
    4.87 +built cleanly, you'd be introducing a lot of noise if you were to tag
    4.88 +every clean build.  Instead, you could tag failed builds (on the
    4.89 +assumption that they're rare!), or simply not use tags to track
    4.90 +buildability.
    4.91 +
    4.92 +If you want to remove a tag that you no longer want, use
    4.93 +\hgcmdargs{tag}{--remove}.  
    4.94 +\interaction{tag.remove}
    4.95 +You can also modify a tag at any time, so that it identifies a
    4.96 +different revision, by simply issuing a new \hgcmd{tag} command.
    4.97 +You'll have to use the \hgopt{tag}{-f} option to tell Mercurial that
    4.98 +you \emph{really} want to update the tag.
    4.99 +\interaction{tag.replace}
   4.100 +There will still be a permanent record of the previous identity of the
   4.101 +tag, but Mercurial will no longer use it.  There's thus no penalty to
   4.102 +tagging the wrong revision; all you have to do is turn around and tag
   4.103 +the correct revision once you discover your error.
   4.104 +
   4.105 +Mercurial stores tags in a normal revision-controlled file in your
   4.106 +repository.  If you've created any tags, you'll find them in a file
   4.107 +named \sfilename{.hgtags}.  When you run the \hgcmd{tag} command,
   4.108 +Mercurial modifies this file, then automatically commits the change to
   4.109 +it.  This means that every time you run \hgcmd{tag}, you'll see a
   4.110 +corresponding changeset in the output of \hgcmd{log}.
   4.111 +\interaction{tag.tip}
   4.112 +
   4.113 +\subsection{Handling tag conflicts during a merge}
   4.114 +
   4.115 +You won't often need to care about the \sfilename{.hgtags} file, but
   4.116 +it sometimes makes its presence known during a merge.  The format of
   4.117 +the file is simple: it consists of a series of lines.  Each line
   4.118 +starts with a changeset hash, followed by a space, followed by the
   4.119 +name of a tag.
   4.120 +
   4.121 +If you're resolving a conflict in the \sfilename{.hgtags} file during
   4.122 +a merge, there's one twist to modifying the \sfilename{.hgtags} file:
   4.123 +when Mercurial is parsing the tags in a repository, it \emph{never}
   4.124 +reads the working copy of the \sfilename{.hgtags} file.  Instead, it
   4.125 +reads the \emph{most recently committed} revision of the file.
   4.126 +
   4.127 +An unfortunate consequence of this design is that you can't actually
   4.128 +verify that your merged \sfilename{.hgtags} file is correct until
   4.129 +\emph{after} you've committed a change.  So if you find yourself
   4.130 +resolving a conflict on \sfilename{.hgtags} during a merge, be sure to
   4.131 +run \hgcmd{tags} after you commit.  If it finds an error in the
   4.132 +\sfilename{.hgtags} file, it will report the location of the error,
   4.133 +which you can then fix and commit.  You should then run \hgcmd{tags}
   4.134 +again, just to be sure that your fix is correct.
   4.135 +
   4.136 +\subsection{Tags and cloning}
   4.137 +
   4.138 +You may have noticed that the \hgcmd{clone} command has a
   4.139 +\hgopt{clone}{-r} option that lets you clone an exact copy of the
   4.140 +repository as of a particular changeset.  The new clone will not
   4.141 +contain any project history that comes after the revision you
   4.142 +specified.  This has an interaction with tags that can surprise the
   4.143 +unwary.
   4.144 +
   4.145 +Recall that a tag is stored as a revision to the \sfilename{.hgtags}
   4.146 +file, so that when you create a tag, the changeset in which it's
   4.147 +recorded necessarily refers to an older changeset.  When you run
   4.148 +\hgcmdargs{clone}{-r foo} to clone a repository as of tag
   4.149 +\texttt{foo}, the new clone \emph{will not contain the history that
   4.150 +  created the tag} that you used to clone the repository.  The result
   4.151 +is that you'll get exactly the right subset of the project's history
   4.152 +in the new repository, but \emph{not} the tag you might have expected.
   4.153 +
   4.154 +\subsection{When permanent tags are too much}
   4.155 +
   4.156 +Since Mercurial's tags are revision controlled and carried around with
   4.157 +a project's history, everyone you work with will see the tags you
   4.158 +create.  But giving names to revisions has uses beyond simply noting
   4.159 +that revision \texttt{4237e45506ee} is really \texttt{v2.0.2}.  If
   4.160 +you're trying to track down a subtle bug, you might want a tag to
   4.161 +remind you of something like ``Anne saw the symptoms with this
   4.162 +revision''.
   4.163 +
   4.164 +For cases like this, what you might want to use are \emph{local} tags.
   4.165 +You can create a local tag with the \hgopt{tag}{-l} option to the
   4.166 +\hgcmd{tag} command.  This will store the tag in a file called
   4.167 +\sfilename{.hg/localtags}.  Unlike \sfilename{.hgtags},
   4.168 +\sfilename{.hg/localtags} is not revision controlled.  Any tags you
   4.169 +create using \hgopt{tag}{-l} remain strictly local to the repository
   4.170 +you're currently working in.
   4.171 +
   4.172 +\section{The flow of changes---big picture vs. little}
   4.173 +
   4.174 +To return to the outline I sketched at the beginning of a chapter,
   4.175 +let's think about a project that has multiple concurrent pieces of
   4.176 +work under development at once.
   4.177 +
   4.178 +There might be a push for a new ``main'' release; a new minor bugfix
   4.179 +release to the last main release; and an unexpected ``hot fix'' to an
   4.180 +old release that is now in maintenance mode.
   4.181 +
   4.182 +The usual way people refer to these different concurrent directions of
   4.183 +development is as ``branches''.  However, we've already seen numerous
   4.184 +times that Mercurial treats \emph{all of history} as a series of
   4.185 +branches and merges.  Really, what we have here is two ideas that are
   4.186 +peripherally related, but which happen to share a name.
   4.187 +\begin{itemize}
   4.188 +\item ``Big picture'' branches represent the sweep of a project's
   4.189 +  evolution; people give them names, and talk about them in
   4.190 +  conversation.
   4.191 +\item ``Little picture'' branches are artefacts of the day-to-day
   4.192 +  activity of developing and merging changes.  They expose the
   4.193 +  narrative of how the code was developed.
   4.194 +\end{itemize}
   4.195 +
   4.196 +\section{Managing big-picture branches in repositories}
   4.197 +
   4.198 +The easiest way to isolate a ``big picture'' branch in Mercurial is in
   4.199 +a dedicated repository.  If you have an existing shared
   4.200 +repository---let's call it \texttt{myproject}---that reaches a ``1.0''
   4.201 +milestone, you can start to prepare for future maintenance releases on
   4.202 +top of version~1.0 by tagging the revision from which you prepared
   4.203 +the~1.0 release.
   4.204 +\interaction{branch-repo.tag}
   4.205 +You can then clone a new shared \texttt{myproject-1.0.1} repository as
   4.206 +of that tag.
   4.207 +\interaction{branch-repo.clone}
   4.208 +
   4.209 +Afterwards, if someone needs to work on a bug fix that ought to go
   4.210 +into an upcoming~1.0.1 minor release, they clone the
   4.211 +\texttt{myproject-1.0.1} repository, make their changes, and push them
   4.212 +back.
   4.213 +\interaction{branch-repo.bugfix}
   4.214 +Meanwhile, development for the next major release can continue,
   4.215 +isolated and unabated, in the \texttt{myproject} repository.
   4.216 +\interaction{branch-repo.new}
   4.217 +
   4.218 +\section{Don't repeat yourself: merging across branches}
   4.219 +
   4.220 +In many cases, if you have a bug to fix on a maintenance branch, the
   4.221 +chances are good that the bug exists on your project's main branch
   4.222 +(and possibly other maintenance branches, too).  It's a rare developer
   4.223 +who wants to fix the same bug multiple times, so let's look at a few
   4.224 +ways that Mercurial can help you to manage these bugfixes without
   4.225 +duplicating your work.
   4.226 +
   4.227 +In the simplest instance, all you need to do is pull changes from your
   4.228 +maintenance branch into your local clone of the target branch.
   4.229 +\interaction{branch-repo.pull}
   4.230 +You'll then need to merge the heads of the two branches, and push back
   4.231 +to the main branch.
   4.232 +\interaction{branch-repo.merge}
   4.233 +
   4.234 +\section{Naming branches within one repository}
   4.235 +
   4.236 +In most instances, isolating branches in repositories is the right
   4.237 +approach.  Its simplicity makes it easy to understand; and so it's
   4.238 +hard to make mistakes.  There's a one-to-one relationship between
   4.239 +branches you're working in and directories on your system.  This lets
   4.240 +you use normal (non-Mercurial-aware) tools to work on files within a
   4.241 +branch/repository.
   4.242 +
   4.243 +If you're more in the ``power user'' category (\emph{and} your
   4.244 +collaborators are too), there is an alternative way of handling
   4.245 +branches that you can consider.  I've already mentioned the
   4.246 +human-level distinction between ``small picture'' and ``big picture''
   4.247 +branches.  While Mercurial works with multiple ``small picture''
   4.248 +branches in a repository all the time (for example after you pull
   4.249 +changes in, but before you merge them), it can \emph{also} work with
   4.250 +multiple ``big picture'' branches.
   4.251 +
   4.252 +The key to working this way is that Mercurial lets you assign a
   4.253 +persistent \emph{name} to a branch.  There always exists a branch
   4.254 +named \texttt{default}.  Even before you start naming branches
   4.255 +yourself, you can find traces of the \texttt{default} branch if you
   4.256 +look for them.
   4.257 +
   4.258 +As an example, when you run the \hgcmd{commit} command, and it pops up
   4.259 +your editor so that you can enter a commit message, look for a line
   4.260 +that contains the text ``\texttt{HG: branch default}'' at the bottom.
   4.261 +This is telling you that your commit will occur on the branch named
   4.262 +\texttt{default}.
   4.263 +
   4.264 +To start working with named branches, use the \hgcmd{branches}
   4.265 +command.  This command lists the named branches already present in
   4.266 +your repository, telling you which changeset is the tip of each.
   4.267 +\interaction{branch-named.branches}
   4.268 +Since you haven't created any named branches yet, the only one that
   4.269 +exists is \texttt{default}.
   4.270 +
   4.271 +To find out what the ``current'' branch is, run the \hgcmd{branch}
   4.272 +command, giving it no arguments.  This tells you what branch the
   4.273 +parent of the current changeset is on.
   4.274 +\interaction{branch-named.branch}
   4.275 +
   4.276 +To create a new branch, run the \hgcmd{branch} command again.  This
   4.277 +time, give it one argument: the name of the branch you want to create.
   4.278 +\interaction{branch-named.create}
   4.279 +
   4.280 +After you've created a branch, you might wonder what effect the
   4.281 +\hgcmd{branch} command has had.  What do the \hgcmd{status} and
   4.282 +\hgcmd{tip} commands report?
   4.283 +\interaction{branch-named.status}
   4.284 +Nothing has changed in the working directory, and there's been no new
   4.285 +history created.  As this suggests, running the \hgcmd{branch} command
   4.286 +has no permanent effect; it only tells Mercurial what branch name to
   4.287 +use the \emph{next} time you commit a changeset.
   4.288 +
   4.289 +When you commit a change, Mercurial records the name of the branch on
   4.290 +which you committed.  Once you've switched from the \texttt{default}
   4.291 +branch to another and committed, you'll see the name of the new branch
   4.292 +show up in the output of \hgcmd{log}, \hgcmd{tip}, and other commands
   4.293 +that display the same kind of output.
   4.294 +\interaction{branch-named.commit}
   4.295 +The \hgcmd{log}-like commands will print the branch name of every
   4.296 +changeset that's not on the \texttt{default} branch.  As a result, if
   4.297 +you never use named branches, you'll never see this information.
   4.298 +
   4.299 +Once you've named a branch and committed a change with that name,
   4.300 +every subsequent commit that descends from that change will inherit
   4.301 +the same branch name.  You can change the name of a branch at any
   4.302 +time, using the \hgcmd{branch} command.  
   4.303 +\interaction{branch-named.rebranch}
   4.304 +In practice, this is something you won't do very often, as branch
   4.305 +names tend to have fairly long lifetimes.  (This isn't a rule, just an
   4.306 +observation.)
   4.307 +
   4.308 +\section{Dealing with multiple named branches in a repository}
   4.309 +
   4.310 +If you have more than one named branch in a repository, Mercurial will
   4.311 +remember the branch that your working directory on when you start a
   4.312 +command like \hgcmd{update} or \hgcmdargs{pull}{-u}.  It will update
   4.313 +the working directory to the tip of this branch, no matter what the
   4.314 +``repo-wide'' tip is.  To update to a revision that's on a different
   4.315 +named branch, you may need to use the \hgopt{update}{-C} option to
   4.316 +\hgcmd{update}.
   4.317 +
   4.318 +This behaviour is a little subtle, so let's see it in action.  First,
   4.319 +let's remind ourselves what branch we're currently on, and what
   4.320 +branches are in our repository.
   4.321 +\interaction{branch-named.parents}
   4.322 +We're on the \texttt{bar} branch, but there also exists an older
   4.323 +\hgcmd{foo} branch.
   4.324 +
   4.325 +We can \hgcmd{update} back and forth between the tips of the
   4.326 +\texttt{foo} and \texttt{bar} branches without needing to use the
   4.327 +\hgopt{update}{-C} option, because this only involves going backwards
   4.328 +and forwards linearly through our change history.
   4.329 +\interaction{branch-named.update-switchy}
   4.330 +
   4.331 +If we go back to the \texttt{foo} branch and then run \hgcmd{update},
   4.332 +it will keep us on \texttt{foo}, not move us to the tip of
   4.333 +\texttt{bar}.
   4.334 +\interaction{branch-named.update-nothing}
   4.335 +
   4.336 +Committing a new change on the \texttt{foo} branch introduces a new
   4.337 +head.
   4.338 +\interaction{branch-named.foo-commit}
   4.339 +
   4.340 +\section{Branch names and merging}
   4.341 +
   4.342 +As you've probably noticed, merges in Mercurial are not symmetrical.
   4.343 +Let's say our repository has two heads, 17 and 23.  If I
   4.344 +\hgcmd{update} to 17 and then \hgcmd{merge} with 23, Mercurial records
   4.345 +17 as the first parent of the merge, and 23 as the second.  Whereas if
   4.346 +I \hgcmd{update} to 23 and then \hgcmd{merge} with 17, it records 23
   4.347 +as the first parent, and 17 as the second.
   4.348 +
   4.349 +This affects Mercurial's choice of branch name when you merge.  After
   4.350 +a merge, Mercurial will retain the branch name of the first parent
   4.351 +when you commit the result of the merge.  If your first parent's
   4.352 +branch name is \texttt{foo}, and you merge with \texttt{bar}, the
   4.353 +branch name will still be \texttt{foo} after you merge.
   4.354 +
   4.355 +It's not unusual for a repository to contain multiple heads, each with
   4.356 +the same branch name.  Let's say I'm working on the \texttt{foo}
   4.357 +branch, and so are you.  We commit different changes; I pull your
   4.358 +changes; I now have two heads, each claiming to be on the \texttt{foo}
   4.359 +branch.  The result of a merge will be a single head on the
   4.360 +\texttt{foo} branch, as you might hope.
   4.361 +
   4.362 +But if I'm working on the \texttt{bar} branch, and I merge work from
   4.363 +the \texttt{foo} branch, the result will remain on the \texttt{bar}
   4.364 +branch.
   4.365 +\interaction{branch-named.merge}
   4.366 +
   4.367 +To give a more concrete example, if I'm working on the
   4.368 +\texttt{bleeding-edge} branch, and I want to bring in the latest fixes
   4.369 +from the \texttt{stable} branch, Mercurial will choose the ``right''
   4.370 +(\texttt{bleeding-edge}) branch name when I pull and merge from
   4.371 +\texttt{stable}.
   4.372 +
   4.373 +\section{Branch naming is generally useful}
   4.374 +
   4.375 +You shouldn't think of named branches as applicable only to situations
   4.376 +where you have multiple long-lived branches cohabiting in a single
   4.377 +repository.  They're very useful even in the one-branch-per-repository
   4.378 +case.  
   4.379 +
   4.380 +In the simplest case, giving a name to each branch gives you a
   4.381 +permanent record of which branch a changeset originated on.  This
   4.382 +gives you more context when you're trying to follow the history of a
   4.383 +long-lived branchy project.
   4.384 +
   4.385 +If you're working with shared repositories, you can set up a
   4.386 +\hook{pretxnchangegroup} hook on each that will block incoming changes
   4.387 +that have the ``wrong'' branch name.  This provides a simple, but
   4.388 +effective, defence against people accidentally pushing changes from a
   4.389 +``bleeding edge'' branch to a ``stable'' branch.  Such a hook might
   4.390 +look like this inside the shared repo's \hgrc.
   4.391 +\begin{codesample2}
   4.392 +  [hooks]
   4.393 +  pretxnchangegroup.branch = hg heads --template '{branches} ' | grep mybranch
   4.394 +\end{codesample2}
   4.395 +
   4.396 +%%% Local Variables: 
   4.397 +%%% mode: latex
   4.398 +%%% TeX-master: "00book"
   4.399 +%%% End: