1.1 --- a/es/branch.tex	Sun Jan 18 22:21:43 2009 -0500
     1.2 +++ b/es/branch.tex	Sun Jan 18 22:31:20 2009 -0500
     1.3 @@ -78,7 +78,7 @@
     1.4  revisiones. Si tiene demasiados tags, la facilidad para identificar
     1.5  revisiones disminuirá rápidamente.
     1.6  
     1.7 -Por ejemplo, si su proyecto tiene etapas(milestones) frecuentes en pocos
     1.8 +Por ejemplo, si su proyecto tiene etapas (milestones) frecuentes en pocos
     1.9  días, es perfectamente razonable asignarle una etiqueta a cada una de
    1.10  ellas. Pero si tiene un sistema de construcción automática de binarios
    1.11  que asegura que cada revisión puede generarse limpiamente, estaría
    1.12 @@ -127,7 +127,7 @@
    1.13  
    1.14  Una consecuencia desafortunada de este diseño es que usted no puede
    1.15  verificar que su fichero \sfilename{.hgtags} fusionado es correcto hasta
    1.16 -\emph{después} de haber consignado(hecho commit). Así que si se
    1.17 +\emph{después} de haber consignado (hecho commit). Así que si se
    1.18  encuentra resolviendo un conflicto en \sfilename{.hgtags} durante una
    1.19  fusión, asegúrese de ejecutar la orden \hgcmd{tags} después de
    1.20  consignar. Si encuentra un error en el fichero \sfilename{.hgtags}, 
    1.21 @@ -214,7 +214,7 @@
    1.22  Posteriormente, si alguien necesita trabajar en la reparación de un
    1.23  fallo debería dirigirse a la liberación de versión~1.0.1 que viene en
    1.24  camino, ellos clonarían el repositorio \texttt{myproject-1.0.1},
    1.25 -harían sus cambios y los publicarían(con push).
    1.26 +harían sus cambios y los publicarían (con push).
    1.27  \interaction{branch-repo.bugfix}
    1.28  Mientras tanto, el desarrollo para la siguiente versión mayor puede
    1.29  continuar asilada e incólume, en el repositorio \texttt{myproject}.
    1.30 @@ -224,7 +224,7 @@
    1.31  
    1.32  En muchos casos, cuando tiene un fallo para arreglar en una rama de
    1.33  mantenimiento, es muy probable que el fallo esté también en la rama
    1.34 -principal( y posiblemente en otras ramas de mantenimiento
    1.35 +principal ( y posiblemente en otras ramas de mantenimiento
    1.36  también). Solamente un desarrollador extraño desearía corregir el
    1.37  mismo fallo muchas veces, por tanto, veremos varias alternativas con
    1.38  las que Mercurial puede ayudarle a administrar tales arreglos de fallo
    1.39 @@ -243,7 +243,7 @@
    1.40  ramas en los repositorios.  Es fácil de entender gracias a su
    1.41  facilidad; y es difícil cometer errores. Hay una relación uno a uno
    1.42  entre las ramas y los directorios con los que está trabajando en su
    1.43 -sistema. Esto le permite usar emplear herramientas usuales(para los
    1.44 +sistema. Esto le permite usar emplear herramientas usuales (para los
    1.45  nuevos a Mercurial) para trabajar con los ficheros dentro de su
    1.46  rama/repositorio.
    1.47  
    1.48 @@ -252,7 +252,7 @@
    1.49  administrar las ramas. He mencionador con anterioridad la distinción a
    1.50  nivel humano entre las ramas estilo ``cuadro pequeño'' y ``gran
    1.51  cuadro''.  Mientras que Mercurial trabaja con muchas ramas del estilo
    1.52 -``cuadro pequeño'' en el repositorio todo el tiempo(por ejemplo cuando
    1.53 +``cuadro pequeño'' en el repositorio todo el tiempo (por ejemplo cuando
    1.54  usted jala cambios, pero antes de fusionarlos), \emph{también} puede
    1.55  trabajar con varias ramas del ``cuadro grande''.
    1.56