1.1 --- a/es/branch.tex	Sun Jan 25 14:13:45 2009 -0500
     1.2 +++ b/es/branch.tex	Sun Jan 25 20:05:48 2009 -0500
     1.3 @@ -85,7 +85,8 @@
     1.4  ellas. Pero si tiene un sistema de construcción automática de binarios
     1.5  que asegura que cada revisión puede generarse limpiamente, estaría
     1.6  introduciendo mucho ruido si se usara una etiqueta para cada generación
     1.7 -exitosa. Más bien, podría usar tags para generaciones fallidas (en
     1.8 +exitosa. Más bien, podría usar tags para generaciones fallidas
     1.9 +(\textexclamdown en
    1.10  caso de que estas sean raras!), o simplemente evitar las etiquetas para
    1.11  llevar cuenta de la posibilidad de generación de binarios.
    1.12  
    1.13 @@ -107,9 +108,10 @@
    1.14  Mercurial almacena las etiquetas en un fichero controlado por revisiones en
    1.15  su repositorio. Si ha creado etiquetas, las encontrará en un fichero
    1.16  llamado \sfilename{.hgtags}.  Cuando invoca la orden \hgcmd{tag},
    1.17 -Mercurial modifica este fichero, y automáticamente hace la consignación del
    1.18 -cambio al mismo.  Esto significa que cada vez que ejecuta \hgcmd{tag},
    1.19 -verá un conjunto de cambios correspondiente en la salida de \hgcmd{log}.
    1.20 +Mercurial modifica este fichero, y hace la consignación del cambio al
    1.21 +mismo automáticamente.  Esto significa que cada vez que ejecuta
    1.22 +\hgcmd{tag}, verá un conjunto de cambios correspondiente en la salida
    1.23 +de \hgcmd{log}.
    1.24  \interaction{tag.tip}
    1.25  
    1.26  \subsection{Manejo de conflictos entre etiquetas durante una fusión}
    1.27 @@ -123,7 +125,7 @@
    1.28  Si está resolviendo un conflicto en el fichero \sfilename{.hgtags}
    1.29  durante una fusión, hay un detalle para tener en cuenta al modificar
    1.30  el fichero \sfilename{.hgtags}:
    1.31 -cuando Mercurial procesa las etiquetas en el repositorio \emph{nunca}
    1.32 +cuando Mercurial procesa las etiquetas en el repositorio, \emph{nunca}
    1.33  lee la copia de trabajo del fichero \sfilename{.hgtags}.  En cambio,
    1.34  lee la versión \emph{consignada más reciente} del fichero.
    1.35  
    1.36 @@ -164,7 +166,7 @@
    1.37  revisiones tiene usos más allá que simplemente hacer notar que la
    1.38  revisión \texttt{4237e45506ee} es realmente \texttt{v2.0.2}.  Si está
    1.39  tratando de encontrar un fallo sutil, posiblemente desearía colocar una 
    1.40 -etiqueta recordándole algo como ``Ana vio los síntomas con esta revisión''.
    1.41 +etiqueta recordándole algo como ``Ana vio los síntomas en esta revisión''.
    1.42  
    1.43  Para estos casos, lo que posiblemente desearía serían etiquetas
    1.44  \emph{locales}. Puede crear una etiqueta local con la opción \hgopt{tag}{-l}
    1.45 @@ -356,22 +358,22 @@
    1.46  si hago \hgcmd{update} a 23 y después aplico \hgcmd{merge} con 17,
    1.47  grabará a 23 como el primer padre, y 17 como el segundo.
    1.48  
    1.49 -Esto afecta el cómo elige Mercurial el nombre de la rama cuando hace
    1.50 -fusión.  Después de una fusión Mercurial mantendrá el nombre de la
    1.51 -rama del primer padre cuando consigne el resultado de una fusión.  Si
    1.52 +Esto afecta el cómo elige Mercurial el nombre de la rama cuando usted
    1.53 +hace la fusión.  Después de una fusión, Mercurial mantendrá el nombre de la
    1.54 +rama del primer padre cuando consigne el resultado de la fusión.  Si
    1.55  el primer nombre de su padre es \texttt{foo}, y fusiona con
    1.56  \texttt{bar}, el nombre de la rama continuará siendo \texttt{foo}
    1.57  después de fusionar.
    1.58  
    1.59  No es inusual que un repositorio contenga varias cabezas, cada una con
    1.60  el mismo nombre de rama.  Digamos que estoy trabajando en la rama
    1.61 -\texttt{foo}, y usted también.  Consignamos cambios distintos; Yo jalo
    1.62 +\texttt{foo}, y usted también.  Consignamos cambios distintos; yo jalo
    1.63  sus cambios; Ahora tengo dos cabezas, cada una afirmando estar en la
    1.64  rama \texttt{foo}.  El resultado de una fusión será una única cabeza
    1.65  en la rama \texttt{foo} como usted esperaría.
    1.66  
    1.67  Pero si estoy trabajando en la rama \texttt{bar}, y fusiono el trabajo
    1.68 -desde la rama \texttt{foo}, el resultado permanecerá en la rama
    1.69 +de la rama \texttt{foo}, el resultado permanecerá en la rama
    1.70  \texttt{bar}.
    1.71  \interaction{branch-named.merge}
    1.72  
    1.73 @@ -383,9 +385,9 @@
    1.74  \section{Normalmente es útil nombrar ramas}
    1.75  
    1.76  No debería considerar que las ramas nombradas son aplicables
    1.77 -únicamente en situaciones con muchas ramas de larga-vida cohabitando
    1.78 +únicamente en situaciones con muchas ramas de larga vida cohabitando
    1.79  en un mismo repositorio.  Son muy útiles incluso en los casos de
    1.80 -una-rama-por-repositorio.
    1.81 +una rama por repositorio.
    1.82  
    1.83  En el caso más sencillo, dar un nombre a cada rama ofrece un registro
    1.84  permanente acerca de en qué conjunto de cambios se generó la rama.
    1.85 @@ -395,8 +397,8 @@
    1.86  Si está trabajando con repositorios compartidos, puede configurar el gancho
    1.87  \hook{pretxnchangegroup} para que cada uno bloquee los cambios con
    1.88  nombres de rama ``incorrectos'' que están por adicionarse.  Este
    1.89 -provee una defensa sencilla pero efectiva para evitar que la gente
    1.90 -accidentalmente publique cambios de una rama ``super nueva'' a la rama
    1.91 +provee una defensa sencilla, pero efectiva, para evitar que la gente
    1.92 +publique accidentalmente cambios de una rama ``super nueva'' a la rama
    1.93  ``estable''.  Tal gancho podría verse de la siguiente forma dentro de
    1.94  un repositorio compartido de \hgrc.
    1.95  \begin{codesample2}