1.1 --- a/es/undo.tex	Sun Jan 18 21:50:48 2009 -0500
     1.2 +++ b/es/undo.tex	Sun Jan 18 22:31:20 2009 -0500
     1.3 @@ -71,7 +71,7 @@
     1.4  repositorio compartido de la versión ``1.0'' en este.  En el peor de
     1.5  los casos, por falta de atención, es posible que publique tales
     1.6  cambios en el árbol compartido ``0.9'', confundiendo a todo su equipo
     1.7 -de trabajo(pero no se preocupe, volveremos a este terrorífico
     1.8 +de trabajo (pero no se preocupe, volveremos a este terrorífico
     1.9  escenario posteriormente).  En todo caso, es muy probable que usted se
    1.10  de cuenta inmediatamente, dado que Mercurial mostrará el URL de donde
    1.11  está jalando, o que vea jalando una sospechosa gran cantidad de
    1.12 @@ -105,7 +105,7 @@
    1.13  repositorio, puede hacer rollback del conjunto de cambios allí, pero
    1.14  es mejor no confiar en una solución de este estilo.  Si lo hace, tarde
    1.15  o temprano un conjunto de cambios logrará colarse en un repositorio
    1.16 -que usted no controle directamente(o del cual se ha olvidado), y
    1.17 +que usted no controle directamente (o del cual se ha olvidado), y
    1.18  volverá a hostigarle.)
    1.19  
    1.20  \subsection{Solamente hay un roll back}
    1.21 @@ -485,7 +485,7 @@
    1.22  trabajo jala cambios de un repositorio central.
    1.23  
    1.24  Al configurar algunos ganchos en el repositorio central para validar
    1.25 -conjuntos de cambios(ver capítulo~\ref{chap:hook}), puede prevenir la
    1.26 +conjuntos de cambios (ver capítulo~\ref{chap:hook}), puede prevenir la
    1.27  publicación automáticamente de cierta clase de cambios malos.  Con tal
    1.28  configuración, cierta clase de conjuntos de cambios malos tenderán
    1.29  naturalmente a``morir'' debido a que no pueden propagarse al
    1.30 @@ -539,7 +539,7 @@
    1.31  Para estos ejemplos debería ser claro que la orden \hgcmd{bisect}
    1.32  es útil no solamente para encontrar la fuente de los fallos. Puede
    1.33  usarla para encontrar cualquier ``propiedad emergente'' de un
    1.34 -repositorio(Cualquier cosa que usted no pueda encontrar con una
    1.35 +repositorio (Cualquier cosa que usted no pueda encontrar con una
    1.36  búsqueda de texto sencilla sobre los ficheros en el árbol) para la
    1.37  cual pueda escribir una prueba binaria.
    1.38  
    1.39 @@ -754,7 +754,7 @@
    1.40  
    1.41  Es posible que este fallo ``enmascare'' completamente al suyo, y que
    1.42  podría haberse revelado antes de que su propio fallo haya tenido
    1.43 -oportunidad de manifestarse. Si no puede saltar el otro fallo(por
    1.44 +oportunidad de manifestarse. Si no puede saltar el otro fallo (por
    1.45  ejemplo, este evita que su proyecto se arme o compile), y de esta
    1.46  forma no se pueda revisar si su fallo esté presente en un conjunto
    1.47  particular de cambios, la orden \hgcmd{bisect} no podrá ayudarle
    1.48 @@ -785,9 +785,9 @@
    1.49  Si no recuerda cuál podría ser el cambio ``bueno'', para informar a
    1.50  \hgcmd{bisect}, podría hacer pruebas aleatorias en el peor de los
    1.51  casos. Pero recuerde eliminar aquellos conjuntos de cambios que
    1.52 -podrían no exhibir el fallo(tal vez porque la característica donde se
    1.53 +podrían no exhibir el fallo (tal vez porque la característica donde se
    1.54  presenta el fallo todavía no está presente) y aquellos en los cuales
    1.55 -otro fallo puede enmascararlo(como se discutió anteriormente).
    1.56 +otro fallo puede enmascararlo (como se discutió anteriormente).
    1.57  
    1.58  Incluso si termina ``muy atrás'' por miles de conjuntos de cambios o
    1.59  meses de historial, solamente estaŕa adicionando unas pruebas contadas