1.1 --- a/es/branch.tex	Fri Oct 17 13:58:54 2008 -0500
     1.2 +++ b/es/branch.tex	Sat Oct 18 03:27:44 2008 -0500
     1.3 @@ -88,130 +88,136 @@
     1.4  llevar cuenta de la posibilidad de generación de binarios.
     1.5  
     1.6  
     1.7 -If you want to remove a tag that you no longer want, use
     1.8 +Si desea eliminar un tag que no desea, use
     1.9  \hgcmdargs{tag}{--remove}.  
    1.10  \interaction{tag.remove}
    1.11 -You can also modify a tag at any time, so that it identifies a
    1.12 -different revision, by simply issuing a new \hgcmd{tag} command.
    1.13 -You'll have to use the \hgopt{tag}{-f} option to tell Mercurial that
    1.14 -you \emph{really} want to update the tag.
    1.15 +También puede modificar un tag en cualquier momento para que
    1.16 +identifique una revisión distinta, basta con aplicar una nueva orden
    1.17 +\hgcmd{tag}. Deberá usar la opción \hgopt{tag}{-f} para indicarle a
    1.18 +Mercurial que desea actualizar el tag \emph{en serio}.
    1.19  \interaction{tag.replace}
    1.20 -There will still be a permanent record of the previous identity of the
    1.21 -tag, but Mercurial will no longer use it.  There's thus no penalty to
    1.22 -tagging the wrong revision; all you have to do is turn around and tag
    1.23 -the correct revision once you discover your error.
    1.24 -
    1.25 -Mercurial stores tags in a normal revision-controlled file in your
    1.26 -repository.  If you've created any tags, you'll find them in a file
    1.27 -named \sfilename{.hgtags}.  When you run the \hgcmd{tag} command,
    1.28 -Mercurial modifies this file, then automatically commits the change to
    1.29 -it.  This means that every time you run \hgcmd{tag}, you'll see a
    1.30 -corresponding changeset in the output of \hgcmd{log}.
    1.31 +De todas maneras habrá un registro permanente de la antigua identidad
    1.32 +del tag, pero Mercurial no la usará. Por lo tanto no hay castigo al
    1.33 +marcar con un tag una revisión incorrecta; lo único que debe hacer es
    1.34 +mover el tag hacia la revisión correcta tan pronto como localice el
    1.35 +error.
    1.36 +
    1.37 +Mercurial almacena los tags en un archivo controlado por revisiones en
    1.38 +su repositorio. Si ha creado tags, los encontrará en un archivo
    1.39 +llamado \sfilename{.hgtags}.  Cuando invoca la orden \hgcmd{tag},
    1.40 +Mercurial modifica este archivo, y automáticamente hace commit del
    1.41 +cambio al mismo.  Esto significa que cada vez que ejecuta \hgcmd{tag},
    1.42 +verá el conjunto de cambios correspondiente en la salida de \hgcmd{log}.
    1.43  \interaction{tag.tip}
    1.44  
    1.45 -\subsection{Handling tag conflicts during a merge}
    1.46 -
    1.47 -You won't often need to care about the \sfilename{.hgtags} file, but
    1.48 -it sometimes makes its presence known during a merge.  The format of
    1.49 -the file is simple: it consists of a series of lines.  Each line
    1.50 -starts with a changeset hash, followed by a space, followed by the
    1.51 -name of a tag.
    1.52 -
    1.53 -If you're resolving a conflict in the \sfilename{.hgtags} file during
    1.54 -a merge, there's one twist to modifying the \sfilename{.hgtags} file:
    1.55 -when Mercurial is parsing the tags in a repository, it \emph{never}
    1.56 -reads the working copy of the \sfilename{.hgtags} file.  Instead, it
    1.57 -reads the \emph{most recently committed} revision of the file.
    1.58 -
    1.59 -An unfortunate consequence of this design is that you can't actually
    1.60 -verify that your merged \sfilename{.hgtags} file is correct until
    1.61 -\emph{after} you've committed a change.  So if you find yourself
    1.62 -resolving a conflict on \sfilename{.hgtags} during a merge, be sure to
    1.63 -run \hgcmd{tags} after you commit.  If it finds an error in the
    1.64 -\sfilename{.hgtags} file, it will report the location of the error,
    1.65 -which you can then fix and commit.  You should then run \hgcmd{tags}
    1.66 -again, just to be sure that your fix is correct.
    1.67 -
    1.68 -\subsection{Tags and cloning}
    1.69 -
    1.70 -You may have noticed that the \hgcmd{clone} command has a
    1.71 -\hgopt{clone}{-r} option that lets you clone an exact copy of the
    1.72 -repository as of a particular changeset.  The new clone will not
    1.73 -contain any project history that comes after the revision you
    1.74 -specified.  This has an interaction with tags that can surprise the
    1.75 -unwary.
    1.76 -
    1.77 -Recall that a tag is stored as a revision to the \sfilename{.hgtags}
    1.78 -file, so that when you create a tag, the changeset in which it's
    1.79 -recorded necessarily refers to an older changeset.  When you run
    1.80 -\hgcmdargs{clone}{-r foo} to clone a repository as of tag
    1.81 -\texttt{foo}, the new clone \emph{will not contain the history that
    1.82 -  created the tag} that you used to clone the repository.  The result
    1.83 -is that you'll get exactly the right subset of the project's history
    1.84 -in the new repository, but \emph{not} the tag you might have expected.
    1.85 -
    1.86 -\subsection{When permanent tags are too much}
    1.87 -
    1.88 -Since Mercurial's tags are revision controlled and carried around with
    1.89 -a project's history, everyone you work with will see the tags you
    1.90 -create.  But giving names to revisions has uses beyond simply noting
    1.91 -that revision \texttt{4237e45506ee} is really \texttt{v2.0.2}.  If
    1.92 -you're trying to track down a subtle bug, you might want a tag to
    1.93 -remind you of something like ``Anne saw the symptoms with this
    1.94 -revision''.
    1.95 -
    1.96 -For cases like this, what you might want to use are \emph{local} tags.
    1.97 -You can create a local tag with the \hgopt{tag}{-l} option to the
    1.98 -\hgcmd{tag} command.  This will store the tag in a file called
    1.99 -\sfilename{.hg/localtags}.  Unlike \sfilename{.hgtags},
   1.100 -\sfilename{.hg/localtags} is not revision controlled.  Any tags you
   1.101 -create using \hgopt{tag}{-l} remain strictly local to the repository
   1.102 -you're currently working in.
   1.103 -
   1.104 -\section{The flow of changes---big picture vs. little}
   1.105 -
   1.106 -To return to the outline I sketched at the beginning of a chapter,
   1.107 -let's think about a project that has multiple concurrent pieces of
   1.108 -work under development at once.
   1.109 -
   1.110 -There might be a push for a new ``main'' release; a new minor bugfix
   1.111 -release to the last main release; and an unexpected ``hot fix'' to an
   1.112 -old release that is now in maintenance mode.
   1.113 -
   1.114 -The usual way people refer to these different concurrent directions of
   1.115 -development is as ``branches''.  However, we've already seen numerous
   1.116 -times that Mercurial treats \emph{all of history} as a series of
   1.117 -branches and merges.  Really, what we have here is two ideas that are
   1.118 -peripherally related, but which happen to share a name.
   1.119 +\subsection{Manejo de conflictos entre tags durante una fusión}
   1.120 +
   1.121 +Es usual no tener que preocuparse por el archivo \sfilename{.hgtags},
   1.122 +pero aveces hace su aparición durante una fusión. El formato del
   1.123 +archivo es sencillo: Consiste de una serie de líneas. Cada línea
   1.124 +comienza con un hash de Conjunto de Cambios, seguido por un espacio,
   1.125 +seguido por el nombre de un tag.
   1.126 +
   1.127 +Si está resolviendo un conflicto en el archivo \sfilename{.hgtags}
   1.128 +durante una fusión, hay un detalle para tener en cuenta al modificar
   1.129 +el archivo \sfilename{.hgtags}:
   1.130 +cuando Mercurial parsea los tags en el repositorio \emph{nunca}
   1.131 +lee la copia de trabajo del archivo \sfilename{.hgtags}.  En cambio,
   1.132 +lee la versión \emph{consignada más reciente} del archivo.
   1.133 +
   1.134 +Una consecuencia desafortunada de este diseño es que usted no puede
   1.135 +verificar que su archivo \sfilename{.hgtags} fusionado es correcto hasta
   1.136 +\emph{después} de haber consignado(hecho commit). Así que si se
   1.137 +encuentra resolviendo un conflicto en \sfilename{.hgtags} durante una
   1.138 +fusión, asegúrese de ejecutar la orden \hgcmd{tags} después de
   1.139 +consignar. Si encuentra un error en el archivo \sfilename{.hgtags}, 
   1.140 +reportará el lugar del error, que podrá arreglar y después
   1.141 +consignar. Posteriormente ejecute de nuevo la orden \hgcmd{tags} para
   1.142 +asegurar que su arreglo fue correctamente aplicado.
   1.143 +
   1.144 +\subsection{Tags y clonado}
   1.145 +
   1.146 +Puede haber notado que la orden \hgcmd{clone} tiene la opción
   1.147 +\hgopt{clone}{-r} que le permite clonar una copia exacta del
   1.148 +repositorio hasta un conjunto de cambios específico. El nuevo clon no
   1.149 +tendrá historia posterior a la revisión que usted haya
   1.150 +especificado. Esta forma de interactuar puede sorprender a los
   1.151 +desprevenidos.
   1.152 +
   1.153 +Recuerde que un tag se almacena como una revisión al archivo
   1.154 +\sfilename{.hgtags}, consecuente con esto, cuando crea un tag, el
   1.155 +conjunto de cambios en el cual este se almacena necesariamente se
   1.156 +refiere a un conjunto de cambios anterior. Cuando ejecuta
   1.157 +\hgcmdargs{clone}{-r foo} para clonar un repositorio hasta el tag
   1.158 +\texttt{foo}, el nuevo clon \emph{no contendrá la historia que creo
   1.159 +el tag} que usó para clonar el repositorio. El resultado es que tendrá
   1.160 +exactamente el subconjunto correcto de la historia del proyecto en el
   1.161 +nuevo repositorio, pero, \emph{no} el tag que podría haber esperado.
   1.162 +
   1.163 +\subsection{Cuando los tags permanentes son demasiado}
   1.164 +
   1.165 +Dado que los tags de Mercurial están controlados por revisiones y se
   1.166 +llevan en la historia del proyecto, todas las personas involucradas
   1.167 +verán los tags que usted haya creado. El hecho de dar nombres a las
   1.168 +revisiones tiene usos más allá que simplemente hacer notar que la
   1.169 +revisión \texttt{4237e45506ee} es realmente \texttt{v2.0.2}.  Si está
   1.170 +tratando de encontrar un bug sutil, posiblemente desearía colocar un
   1.171 +tag recordándole algo como ``Ana vió los síntomas con esta revisión''.
   1.172 +
   1.173 +Para estos casos, lo que posiblemente desearía serían tags
   1.174 +\emph{locales}. Puede crear un tag local con la opción \hgopt{tag}{-l}
   1.175 +de la orden \hgcmd{tag}.  Esto guardará el tag en un archivo llamado
   1.176 +\sfilename{.hg/localtags}.  A diferencia de \sfilename{.hgtags},
   1.177 +\sfilename{.hg/localtags} no está controlado por revisiones.
   1.178 +Cualquier tag que usted cree usando \hgopt{tag}{-l} se mantendrá
   1.179 +localmente en el repositorio en el que esté trabajando en ese momento.
   1.180 +
   1.181 +\section{El flujo de cambios---El gran cuadro vs. el pequeño}
   1.182 +
   1.183 +Retomando lo mencionado en el comienzo de un capítulo, pensemos en el
   1.184 +hecho de que un proyecto tiene muchas piezas concurrentes de trabajo
   1.185 +en desarrollo al mismo tiempo.
   1.186 +
   1.187 +Puede haber prisa por una nueva versión ``principal''; Un nueva
   1.188 +versión con un rreglo de fallo a la última versión; y una versión de
   1.189 +``mantenimiento correctivo'' a una versión antigua que ha entrado en
   1.190 +modo de mantenimiento.
   1.191 +
   1.192 +Usualmente la gente se refiere a esas direcciones
   1.193 +concurrentes de desarrollo es como ``ramas''.  Aunque hemos visto que
   1.194 +en variadas ocasiones Mercurial trata a \emph{toda la historia} como
   1.195 +una serie de ramas y fusiones.  Realmente lo que tenemos aquí es dos
   1.196 +ideas que se relacionan periféricamente, pero que en esencia comparten
   1.197 +un nombre.
   1.198  \begin{itemize}
   1.199 -\item ``Big picture'' branches represent the sweep of a project's
   1.200 -  evolution; people give them names, and talk about them in
   1.201 -  conversation.
   1.202 -\item ``Little picture'' branches are artefacts of the day-to-day
   1.203 -  activity of developing and merging changes.  They expose the
   1.204 -  narrative of how the code was developed.
   1.205 +\item ``El gran cuadro'' Las ramas representan un barrido de la
   1.206 +  evolución del proyecto; la gente les da nombres y hablan acerca de
   1.207 +  ellas en sus conversaciones.
   1.208 +\item ``El cuadro pequeño'' Las ramas son artefactos de las
   1.209 +  actividades diarias de al desarrollar y fusionar cambios. Exponen la
   1.210 +  narrativa de cómo se desarrolló el código.
   1.211  \end{itemize}
   1.212  
   1.213 -\section{Managing big-picture branches in repositories}
   1.214 +\section{Administrar ramas en el gran cuadro en los repositorios}
   1.215  
   1.216  The easiest way to isolate a ``big picture'' branch in Mercurial is in
   1.217 -a dedicated repository.  If you have an existing shared
   1.218 -repository---let's call it \texttt{myproject}---that reaches a ``1.0''
   1.219 +a dedicated repositorio.  If you have an existing shared
   1.220 +repositorio---let's call it \texttt{myproject}---that reaches a ``1.0''
   1.221  milestone, you can start to prepare for future maintenance releases on
   1.222  top of version~1.0 by tagging the revision from which you prepared
   1.223  the~1.0 release.
   1.224  \interaction{branch-repo.tag}
   1.225 -You can then clone a new shared \texttt{myproject-1.0.1} repository as
   1.226 +You can then clone a new shared \texttt{myproject-1.0.1} repositorio as
   1.227  of that tag.
   1.228  \interaction{branch-repo.clone}
   1.229  
   1.230  Afterwards, if someone needs to work on a bug fix that ought to go
   1.231  into an upcoming~1.0.1 minor release, they clone the
   1.232 -\texttt{myproject-1.0.1} repository, make their changes, and push them
   1.233 +\texttt{myproject-1.0.1} repositorio, make their changes, and push them
   1.234  back.
   1.235  \interaction{branch-repo.bugfix}
   1.236  Meanwhile, development for the next major release can continue,
   1.237 -isolated and unabated, in the \texttt{myproject} repository.
   1.238 +isolated and unabated, in the \texttt{myproject} repositorio.
   1.239  \interaction{branch-repo.new}
   1.240  
   1.241  \section{Don't repeat yourself: merging across branches}
   1.242 @@ -230,21 +236,21 @@
   1.243  to the main branch.
   1.244  \interaction{branch-repo.merge}
   1.245  
   1.246 -\section{Naming branches within one repository}
   1.247 -
   1.248 -In most instances, isolating branches in repositories is the right
   1.249 +\section{Naming branches within one repositorio}
   1.250 +
   1.251 +In most instances, isolating branches in repositorios is the right
   1.252  approach.  Its simplicity makes it easy to understand; and so it's
   1.253  hard to make mistakes.  There's a one-to-one relationship between
   1.254  branches you're working in and directories on your system.  This lets
   1.255  you use normal (non-Mercurial-aware) tools to work on files within a
   1.256 -branch/repository.
   1.257 +branch/repositorio.
   1.258  
   1.259  If you're more in the ``power user'' category (\emph{and} your
   1.260  collaborators are too), there is an alternative way of handling
   1.261  branches that you can consider.  I've already mentioned the
   1.262  human-level distinction between ``small picture'' and ``big picture''
   1.263  branches.  While Mercurial works with multiple ``small picture''
   1.264 -branches in a repository all the time (for example after you pull
   1.265 +branches in a repositorio all the time (for example after you pull
   1.266  changes in, but before you merge them), it can \emph{also} work with
   1.267  multiple ``big picture'' branches.
   1.268  
   1.269 @@ -262,7 +268,7 @@
   1.270  
   1.271  To start working with named branches, use the \hgcmd{branches}
   1.272  command.  This command lists the named branches already present in
   1.273 -your repository, telling you which changeset is the tip of each.
   1.274 +your repositorio, telling you which changeset is the tip of each.
   1.275  \interaction{branch-named.branches}
   1.276  Since you haven't created any named branches yet, the only one that
   1.277  exists is \texttt{default}.
   1.278 @@ -304,9 +310,9 @@
   1.279  names tend to have fairly long lifetimes.  (This isn't a rule, just an
   1.280  observation.)
   1.281  
   1.282 -\section{Dealing with multiple named branches in a repository}
   1.283 -
   1.284 -If you have more than one named branch in a repository, Mercurial will
   1.285 +\section{Dealing with multiple named branches in a repositorio}
   1.286 +
   1.287 +If you have more than one named branch in a repositorio, Mercurial will
   1.288  remember the branch that your working directory on when you start a
   1.289  command like \hgcmd{update} or \hgcmdargs{pull}{-u}.  It will update
   1.290  the working directory to the tip of this branch, no matter what the
   1.291 @@ -316,7 +322,7 @@
   1.292  
   1.293  This behaviour is a little subtle, so let's see it in action.  First,
   1.294  let's remind ourselves what branch we're currently on, and what
   1.295 -branches are in our repository.
   1.296 +branches are in our repositorio.
   1.297  \interaction{branch-named.parents}
   1.298  We're on the \texttt{bar} branch, but there also exists an older
   1.299  \hgcmd{foo} branch.
   1.300 @@ -339,7 +345,7 @@
   1.301  \section{Branch names and merging}
   1.302  
   1.303  As you've probably noticed, merges in Mercurial are not symmetrical.
   1.304 -Let's say our repository has two heads, 17 and 23.  If I
   1.305 +Let's say our repositorio has two heads, 17 and 23.  If I
   1.306  \hgcmd{update} to 17 and then \hgcmd{merge} with 23, Mercurial records
   1.307  17 as the first parent of the merge, and 23 as the second.  Whereas if
   1.308  I \hgcmd{update} to 23 and then \hgcmd{merge} with 17, it records 23
   1.309 @@ -351,7 +357,7 @@
   1.310  branch name is \texttt{foo}, and you merge with \texttt{bar}, the
   1.311  branch name will still be \texttt{foo} after you merge.
   1.312  
   1.313 -It's not unusual for a repository to contain multiple heads, each with
   1.314 +It's not unusual for a repositorio to contain multiple heads, each with
   1.315  the same branch name.  Let's say I'm working on the \texttt{foo}
   1.316  branch, and so are you.  We commit different changes; I pull your
   1.317  changes; I now have two heads, each claiming to be on the \texttt{foo}
   1.318 @@ -373,7 +379,7 @@
   1.319  
   1.320  You shouldn't think of named branches as applicable only to situations
   1.321  where you have multiple long-lived branches cohabiting in a single
   1.322 -repository.  They're very useful even in the one-branch-per-repository
   1.323 +repositorio.  They're very useful even in the one-branch-per-repositorio
   1.324  case.  
   1.325  
   1.326  In the simplest case, giving a name to each branch gives you a
   1.327 @@ -381,7 +387,7 @@
   1.328  gives you more context when you're trying to follow the history of a
   1.329  long-lived branchy project.
   1.330  
   1.331 -If you're working with shared repositories, you can set up a
   1.332 +If you're working with shared repositorios, you can set up a
   1.333  \hook{pretxnchangegroup} hook on each that will block incoming changes
   1.334  that have the ``wrong'' branch name.  This provides a simple, but
   1.335  effective, defence against people accidentally pushing changes from a