diff es/undo.tex @ 619:bbc5db74bd77

changed many "X(" for "X (" I did this only when inside the main text

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