1.1 --- a/es/Leame.1st	Fri Oct 17 13:58:54 2008 -0500
     1.2 +++ b/es/Leame.1st	Sat Oct 18 03:27:44 2008 -0500
     1.3 @@ -27,7 +27,10 @@
     1.4  
     1.5   Branch: Rama
     1.6   Bug: Fallo
     1.7 + Changeset: Conjunto de Cambios
     1.8   Command: Orden
     1.9 + Commit: Consignar
    1.10 + Merge: Fusión
    1.11   Milestone: Etapa
    1.12   Release: Versión o liberación de versión
    1.13  

     2.1 --- a/es/branch.tex	Fri Oct 17 13:58:54 2008 -0500
     2.2 +++ b/es/branch.tex	Sat Oct 18 03:27:44 2008 -0500
     2.3 @@ -88,130 +88,136 @@
     2.4  llevar cuenta de la posibilidad de generación de binarios.
     2.5  
     2.6  
     2.7 -If you want to remove a tag that you no longer want, use
     2.8 +Si desea eliminar un tag que no desea, use
     2.9  \hgcmdargs{tag}{--remove}.  
    2.10  \interaction{tag.remove}
    2.11 -You can also modify a tag at any time, so that it identifies a
    2.12 -different revision, by simply issuing a new \hgcmd{tag} command.
    2.13 -You'll have to use the \hgopt{tag}{-f} option to tell Mercurial that
    2.14 -you \emph{really} want to update the tag.
    2.15 +También puede modificar un tag en cualquier momento para que
    2.16 +identifique una revisión distinta, basta con aplicar una nueva orden
    2.17 +\hgcmd{tag}. Deberá usar la opción \hgopt{tag}{-f} para indicarle a
    2.18 +Mercurial que desea actualizar el tag \emph{en serio}.
    2.19  \interaction{tag.replace}
    2.20 -There will still be a permanent record of the previous identity of the
    2.21 -tag, but Mercurial will no longer use it.  There's thus no penalty to
    2.22 -tagging the wrong revision; all you have to do is turn around and tag
    2.23 -the correct revision once you discover your error.
    2.24 -
    2.25 -Mercurial stores tags in a normal revision-controlled file in your
    2.26 -repository.  If you've created any tags, you'll find them in a file
    2.27 -named \sfilename{.hgtags}.  When you run the \hgcmd{tag} command,
    2.28 -Mercurial modifies this file, then automatically commits the change to
    2.29 -it.  This means that every time you run \hgcmd{tag}, you'll see a
    2.30 -corresponding changeset in the output of \hgcmd{log}.
    2.31 +De todas maneras habrá un registro permanente de la antigua identidad
    2.32 +del tag, pero Mercurial no la usará. Por lo tanto no hay castigo al
    2.33 +marcar con un tag una revisión incorrecta; lo único que debe hacer es
    2.34 +mover el tag hacia la revisión correcta tan pronto como localice el
    2.35 +error.
    2.36 +
    2.37 +Mercurial almacena los tags en un archivo controlado por revisiones en
    2.38 +su repositorio. Si ha creado tags, los encontrará en un archivo
    2.39 +llamado \sfilename{.hgtags}.  Cuando invoca la orden \hgcmd{tag},
    2.40 +Mercurial modifica este archivo, y automáticamente hace commit del
    2.41 +cambio al mismo.  Esto significa que cada vez que ejecuta \hgcmd{tag},
    2.42 +verá el conjunto de cambios correspondiente en la salida de \hgcmd{log}.
    2.43  \interaction{tag.tip}
    2.44  
    2.45 -\subsection{Handling tag conflicts during a merge}
    2.46 -
    2.47 -You won't often need to care about the \sfilename{.hgtags} file, but
    2.48 -it sometimes makes its presence known during a merge.  The format of
    2.49 -the file is simple: it consists of a series of lines.  Each line
    2.50 -starts with a changeset hash, followed by a space, followed by the
    2.51 -name of a tag.
    2.52 -
    2.53 -If you're resolving a conflict in the \sfilename{.hgtags} file during
    2.54 -a merge, there's one twist to modifying the \sfilename{.hgtags} file:
    2.55 -when Mercurial is parsing the tags in a repository, it \emph{never}
    2.56 -reads the working copy of the \sfilename{.hgtags} file.  Instead, it
    2.57 -reads the \emph{most recently committed} revision of the file.
    2.58 -
    2.59 -An unfortunate consequence of this design is that you can't actually
    2.60 -verify that your merged \sfilename{.hgtags} file is correct until
    2.61 -\emph{after} you've committed a change.  So if you find yourself
    2.62 -resolving a conflict on \sfilename{.hgtags} during a merge, be sure to
    2.63 -run \hgcmd{tags} after you commit.  If it finds an error in the
    2.64 -\sfilename{.hgtags} file, it will report the location of the error,
    2.65 -which you can then fix and commit.  You should then run \hgcmd{tags}
    2.66 -again, just to be sure that your fix is correct.
    2.67 -
    2.68 -\subsection{Tags and cloning}
    2.69 -
    2.70 -You may have noticed that the \hgcmd{clone} command has a
    2.71 -\hgopt{clone}{-r} option that lets you clone an exact copy of the
    2.72 -repository as of a particular changeset.  The new clone will not
    2.73 -contain any project history that comes after the revision you
    2.74 -specified.  This has an interaction with tags that can surprise the
    2.75 -unwary.
    2.76 -
    2.77 -Recall that a tag is stored as a revision to the \sfilename{.hgtags}
    2.78 -file, so that when you create a tag, the changeset in which it's
    2.79 -recorded necessarily refers to an older changeset.  When you run
    2.80 -\hgcmdargs{clone}{-r foo} to clone a repository as of tag
    2.81 -\texttt{foo}, the new clone \emph{will not contain the history that
    2.82 -  created the tag} that you used to clone the repository.  The result
    2.83 -is that you'll get exactly the right subset of the project's history
    2.84 -in the new repository, but \emph{not} the tag you might have expected.
    2.85 -
    2.86 -\subsection{When permanent tags are too much}
    2.87 -
    2.88 -Since Mercurial's tags are revision controlled and carried around with
    2.89 -a project's history, everyone you work with will see the tags you
    2.90 -create.  But giving names to revisions has uses beyond simply noting
    2.91 -that revision \texttt{4237e45506ee} is really \texttt{v2.0.2}.  If
    2.92 -you're trying to track down a subtle bug, you might want a tag to
    2.93 -remind you of something like ``Anne saw the symptoms with this
    2.94 -revision''.
    2.95 -
    2.96 -For cases like this, what you might want to use are \emph{local} tags.
    2.97 -You can create a local tag with the \hgopt{tag}{-l} option to the
    2.98 -\hgcmd{tag} command.  This will store the tag in a file called
    2.99 -\sfilename{.hg/localtags}.  Unlike \sfilename{.hgtags},
   2.100 -\sfilename{.hg/localtags} is not revision controlled.  Any tags you
   2.101 -create using \hgopt{tag}{-l} remain strictly local to the repository
   2.102 -you're currently working in.
   2.103 -
   2.104 -\section{The flow of changes---big picture vs. little}
   2.105 -
   2.106 -To return to the outline I sketched at the beginning of a chapter,
   2.107 -let's think about a project that has multiple concurrent pieces of
   2.108 -work under development at once.
   2.109 -
   2.110 -There might be a push for a new ``main'' release; a new minor bugfix
   2.111 -release to the last main release; and an unexpected ``hot fix'' to an
   2.112 -old release that is now in maintenance mode.
   2.113 -
   2.114 -The usual way people refer to these different concurrent directions of
   2.115 -development is as ``branches''.  However, we've already seen numerous
   2.116 -times that Mercurial treats \emph{all of history} as a series of
   2.117 -branches and merges.  Really, what we have here is two ideas that are
   2.118 -peripherally related, but which happen to share a name.
   2.119 +\subsection{Manejo de conflictos entre tags durante una fusión}
   2.120 +
   2.121 +Es usual no tener que preocuparse por el archivo \sfilename{.hgtags},
   2.122 +pero aveces hace su aparición durante una fusión. El formato del
   2.123 +archivo es sencillo: Consiste de una serie de líneas. Cada línea
   2.124 +comienza con un hash de Conjunto de Cambios, seguido por un espacio,
   2.125 +seguido por el nombre de un tag.
   2.126 +
   2.127 +Si está resolviendo un conflicto en el archivo \sfilename{.hgtags}
   2.128 +durante una fusión, hay un detalle para tener en cuenta al modificar
   2.129 +el archivo \sfilename{.hgtags}:
   2.130 +cuando Mercurial parsea los tags en el repositorio \emph{nunca}
   2.131 +lee la copia de trabajo del archivo \sfilename{.hgtags}.  En cambio,
   2.132 +lee la versión \emph{consignada más reciente} del archivo.
   2.133 +
   2.134 +Una consecuencia desafortunada de este diseño es que usted no puede
   2.135 +verificar que su archivo \sfilename{.hgtags} fusionado es correcto hasta
   2.136 +\emph{después} de haber consignado(hecho commit). Así que si se
   2.137 +encuentra resolviendo un conflicto en \sfilename{.hgtags} durante una
   2.138 +fusión, asegúrese de ejecutar la orden \hgcmd{tags} después de
   2.139 +consignar. Si encuentra un error en el archivo \sfilename{.hgtags}, 
   2.140 +reportará el lugar del error, que podrá arreglar y después
   2.141 +consignar. Posteriormente ejecute de nuevo la orden \hgcmd{tags} para
   2.142 +asegurar que su arreglo fue correctamente aplicado.
   2.143 +
   2.144 +\subsection{Tags y clonado}
   2.145 +
   2.146 +Puede haber notado que la orden \hgcmd{clone} tiene la opción
   2.147 +\hgopt{clone}{-r} que le permite clonar una copia exacta del
   2.148 +repositorio hasta un conjunto de cambios específico. El nuevo clon no
   2.149 +tendrá historia posterior a la revisión que usted haya
   2.150 +especificado. Esta forma de interactuar puede sorprender a los
   2.151 +desprevenidos.
   2.152 +
   2.153 +Recuerde que un tag se almacena como una revisión al archivo
   2.154 +\sfilename{.hgtags}, consecuente con esto, cuando crea un tag, el
   2.155 +conjunto de cambios en el cual este se almacena necesariamente se
   2.156 +refiere a un conjunto de cambios anterior. Cuando ejecuta
   2.157 +\hgcmdargs{clone}{-r foo} para clonar un repositorio hasta el tag
   2.158 +\texttt{foo}, el nuevo clon \emph{no contendrá la historia que creo
   2.159 +el tag} que usó para clonar el repositorio. El resultado es que tendrá
   2.160 +exactamente el subconjunto correcto de la historia del proyecto en el
   2.161 +nuevo repositorio, pero, \emph{no} el tag que podría haber esperado.
   2.162 +
   2.163 +\subsection{Cuando los tags permanentes son demasiado}
   2.164 +
   2.165 +Dado que los tags de Mercurial están controlados por revisiones y se
   2.166 +llevan en la historia del proyecto, todas las personas involucradas
   2.167 +verán los tags que usted haya creado. El hecho de dar nombres a las
   2.168 +revisiones tiene usos más allá que simplemente hacer notar que la
   2.169 +revisión \texttt{4237e45506ee} es realmente \texttt{v2.0.2}.  Si está
   2.170 +tratando de encontrar un bug sutil, posiblemente desearía colocar un
   2.171 +tag recordándole algo como ``Ana vió los síntomas con esta revisión''.
   2.172 +
   2.173 +Para estos casos, lo que posiblemente desearía serían tags
   2.174 +\emph{locales}. Puede crear un tag local con la opción \hgopt{tag}{-l}
   2.175 +de la orden \hgcmd{tag}.  Esto guardará el tag en un archivo llamado
   2.176 +\sfilename{.hg/localtags}.  A diferencia de \sfilename{.hgtags},
   2.177 +\sfilename{.hg/localtags} no está controlado por revisiones.
   2.178 +Cualquier tag que usted cree usando \hgopt{tag}{-l} se mantendrá
   2.179 +localmente en el repositorio en el que esté trabajando en ese momento.
   2.180 +
   2.181 +\section{El flujo de cambios---El gran cuadro vs. el pequeño}
   2.182 +
   2.183 +Retomando lo mencionado en el comienzo de un capítulo, pensemos en el
   2.184 +hecho de que un proyecto tiene muchas piezas concurrentes de trabajo
   2.185 +en desarrollo al mismo tiempo.
   2.186 +
   2.187 +Puede haber prisa por una nueva versión ``principal''; Un nueva
   2.188 +versión con un rreglo de fallo a la última versión; y una versión de
   2.189 +``mantenimiento correctivo'' a una versión antigua que ha entrado en
   2.190 +modo de mantenimiento.
   2.191 +
   2.192 +Usualmente la gente se refiere a esas direcciones
   2.193 +concurrentes de desarrollo es como ``ramas''.  Aunque hemos visto que
   2.194 +en variadas ocasiones Mercurial trata a \emph{toda la historia} como
   2.195 +una serie de ramas y fusiones.  Realmente lo que tenemos aquí es dos
   2.196 +ideas que se relacionan periféricamente, pero que en esencia comparten
   2.197 +un nombre.
   2.198  \begin{itemize}
   2.199 -\item ``Big picture'' branches represent the sweep of a project's
   2.200 -  evolution; people give them names, and talk about them in
   2.201 -  conversation.
   2.202 -\item ``Little picture'' branches are artefacts of the day-to-day
   2.203 -  activity of developing and merging changes.  They expose the
   2.204 -  narrative of how the code was developed.
   2.205 +\item ``El gran cuadro'' Las ramas representan un barrido de la
   2.206 +  evolución del proyecto; la gente les da nombres y hablan acerca de
   2.207 +  ellas en sus conversaciones.
   2.208 +\item ``El cuadro pequeño'' Las ramas son artefactos de las
   2.209 +  actividades diarias de al desarrollar y fusionar cambios. Exponen la
   2.210 +  narrativa de cómo se desarrolló el código.
   2.211  \end{itemize}
   2.212  
   2.213 -\section{Managing big-picture branches in repositories}
   2.214 +\section{Administrar ramas en el gran cuadro en los repositorios}
   2.215  
   2.216  The easiest way to isolate a ``big picture'' branch in Mercurial is in
   2.217 -a dedicated repository.  If you have an existing shared
   2.218 -repository---let's call it \texttt{myproject}---that reaches a ``1.0''
   2.219 +a dedicated repositorio.  If you have an existing shared
   2.220 +repositorio---let's call it \texttt{myproject}---that reaches a ``1.0''
   2.221  milestone, you can start to prepare for future maintenance releases on
   2.222  top of version~1.0 by tagging the revision from which you prepared
   2.223  the~1.0 release.
   2.224  \interaction{branch-repo.tag}
   2.225 -You can then clone a new shared \texttt{myproject-1.0.1} repository as
   2.226 +You can then clone a new shared \texttt{myproject-1.0.1} repositorio as
   2.227  of that tag.
   2.228  \interaction{branch-repo.clone}
   2.229  
   2.230  Afterwards, if someone needs to work on a bug fix that ought to go
   2.231  into an upcoming~1.0.1 minor release, they clone the
   2.232 -\texttt{myproject-1.0.1} repository, make their changes, and push them
   2.233 +\texttt{myproject-1.0.1} repositorio, make their changes, and push them
   2.234  back.
   2.235  \interaction{branch-repo.bugfix}
   2.236  Meanwhile, development for the next major release can continue,
   2.237 -isolated and unabated, in the \texttt{myproject} repository.
   2.238 +isolated and unabated, in the \texttt{myproject} repositorio.
   2.239  \interaction{branch-repo.new}
   2.240  
   2.241  \section{Don't repeat yourself: merging across branches}
   2.242 @@ -230,21 +236,21 @@
   2.243  to the main branch.
   2.244  \interaction{branch-repo.merge}
   2.245  
   2.246 -\section{Naming branches within one repository}
   2.247 -
   2.248 -In most instances, isolating branches in repositories is the right
   2.249 +\section{Naming branches within one repositorio}
   2.250 +
   2.251 +In most instances, isolating branches in repositorios is the right
   2.252  approach.  Its simplicity makes it easy to understand; and so it's
   2.253  hard to make mistakes.  There's a one-to-one relationship between
   2.254  branches you're working in and directories on your system.  This lets
   2.255  you use normal (non-Mercurial-aware) tools to work on files within a
   2.256 -branch/repository.
   2.257 +branch/repositorio.
   2.258  
   2.259  If you're more in the ``power user'' category (\emph{and} your
   2.260  collaborators are too), there is an alternative way of handling
   2.261  branches that you can consider.  I've already mentioned the
   2.262  human-level distinction between ``small picture'' and ``big picture''
   2.263  branches.  While Mercurial works with multiple ``small picture''
   2.264 -branches in a repository all the time (for example after you pull
   2.265 +branches in a repositorio all the time (for example after you pull
   2.266  changes in, but before you merge them), it can \emph{also} work with
   2.267  multiple ``big picture'' branches.
   2.268  
   2.269 @@ -262,7 +268,7 @@
   2.270  
   2.271  To start working with named branches, use the \hgcmd{branches}
   2.272  command.  This command lists the named branches already present in
   2.273 -your repository, telling you which changeset is the tip of each.
   2.274 +your repositorio, telling you which changeset is the tip of each.
   2.275  \interaction{branch-named.branches}
   2.276  Since you haven't created any named branches yet, the only one that
   2.277  exists is \texttt{default}.
   2.278 @@ -304,9 +310,9 @@
   2.279  names tend to have fairly long lifetimes.  (This isn't a rule, just an
   2.280  observation.)
   2.281  
   2.282 -\section{Dealing with multiple named branches in a repository}
   2.283 -
   2.284 -If you have more than one named branch in a repository, Mercurial will
   2.285 +\section{Dealing with multiple named branches in a repositorio}
   2.286 +
   2.287 +If you have more than one named branch in a repositorio, Mercurial will
   2.288  remember the branch that your working directory on when you start a
   2.289  command like \hgcmd{update} or \hgcmdargs{pull}{-u}.  It will update
   2.290  the working directory to the tip of this branch, no matter what the
   2.291 @@ -316,7 +322,7 @@
   2.292  
   2.293  This behaviour is a little subtle, so let's see it in action.  First,
   2.294  let's remind ourselves what branch we're currently on, and what
   2.295 -branches are in our repository.
   2.296 +branches are in our repositorio.
   2.297  \interaction{branch-named.parents}
   2.298  We're on the \texttt{bar} branch, but there also exists an older
   2.299  \hgcmd{foo} branch.
   2.300 @@ -339,7 +345,7 @@
   2.301  \section{Branch names and merging}
   2.302  
   2.303  As you've probably noticed, merges in Mercurial are not symmetrical.
   2.304 -Let's say our repository has two heads, 17 and 23.  If I
   2.305 +Let's say our repositorio has two heads, 17 and 23.  If I
   2.306  \hgcmd{update} to 17 and then \hgcmd{merge} with 23, Mercurial records
   2.307  17 as the first parent of the merge, and 23 as the second.  Whereas if
   2.308  I \hgcmd{update} to 23 and then \hgcmd{merge} with 17, it records 23
   2.309 @@ -351,7 +357,7 @@
   2.310  branch name is \texttt{foo}, and you merge with \texttt{bar}, the
   2.311  branch name will still be \texttt{foo} after you merge.
   2.312  
   2.313 -It's not unusual for a repository to contain multiple heads, each with
   2.314 +It's not unusual for a repositorio to contain multiple heads, each with
   2.315  the same branch name.  Let's say I'm working on the \texttt{foo}
   2.316  branch, and so are you.  We commit different changes; I pull your
   2.317  changes; I now have two heads, each claiming to be on the \texttt{foo}
   2.318 @@ -373,7 +379,7 @@
   2.319  
   2.320  You shouldn't think of named branches as applicable only to situations
   2.321  where you have multiple long-lived branches cohabiting in a single
   2.322 -repository.  They're very useful even in the one-branch-per-repository
   2.323 +repositorio.  They're very useful even in the one-branch-per-repositorio
   2.324  case.  
   2.325  
   2.326  In the simplest case, giving a name to each branch gives you a
   2.327 @@ -381,7 +387,7 @@
   2.328  gives you more context when you're trying to follow the history of a
   2.329  long-lived branchy project.
   2.330  
   2.331 -If you're working with shared repositories, you can set up a
   2.332 +If you're working with shared repositorios, you can set up a
   2.333  \hook{pretxnchangegroup} hook on each that will block incoming changes
   2.334  that have the ``wrong'' branch name.  This provides a simple, but
   2.335  effective, defence against people accidentally pushing changes from a