1.1 --- a/es/Leame.1st	Thu Nov 06 23:07:42 2008 -0500
     1.2 +++ b/es/Leame.1st	Thu Nov 06 23:09:47 2008 -0500
     1.3 @@ -99,7 +99,7 @@
     1.4  || preface.tex     || Javier Rojas  ||    100%    || 18/10/2008 ||  19/10/2008 ||
     1.5  || daily.tex       || Igor Támara   ||    100%    || 19/10/2008 ||  26/10/2008 ||
     1.6  || tour-basic.tex  || Javier Rojas  ||    100%    || 19/10/2008 ||  27/10/2008 ||
     1.7 -|| undo.tex        || Igor Támara   ||     71%    || 26/10/2008 ||             ||
     1.8 +|| undo.tex        || Igor Támara   ||     85%    || 26/10/2008 ||             ||
     1.9  || tour-merge.tex  || Javier Rojas  ||    100%    || 28/10/2008 ||  03/11/2008 ||
    1.10  || concepts.tex    || Javier Rojas  ||      7%    || 03/11/2008 ||             ||
    1.11  

     2.1 --- a/es/undo.tex	Thu Nov 06 23:07:42 2008 -0500
     2.2 +++ b/es/undo.tex	Thu Nov 06 23:09:47 2008 -0500
     2.3 @@ -205,7 +205,7 @@
     2.4  nuevo nombre, al revertir ambos componentes del renombramiento, cuando
     2.5  Mercurial restaure el fichero que fue eliminado como parte del
     2.6  renombramiento, no será modificado.
     2.7 -Si necesita que las modificaciones en el archivo destino del
     2.8 +Si necesita que las modificaciones en el fichero destino del
     2.9  renombramiento se muestren, no olvide copiarlas encima.)
    2.10  
    2.11  Estos aspectos engorrosos al revertir un renombramiento se constituyen
    2.12 @@ -359,7 +359,7 @@
    2.13  muestra que el tercer camlio es una cabeza separada, \emph{no}
    2.14  esperamos ver el tercer cambio presente en \filename{myfile}.
    2.15  \interaction{backout.manual.cat}
    2.16 -Para que el tercer cambio esté en el archivo, hacemos una fusión usual
    2.17 +Para que el tercer cambio esté en el fichero, hacemos una fusión usual
    2.18  de las dos cabezas.
    2.19  \interaction{backout.manual.merge}
    2.20  Después de eso, la historia gráfica de nuestro repositorio luce como
    2.21 @@ -385,7 +385,7 @@
    2.22    retroceder. Lo llamaremos \texttt{backout}
    2.23  \item Encuentra el padre del conjunto de cambios. Lo llamaremos
    2.24    \texttt{parent}.
    2.25 -\item Para cada archivo del conjunto de cambios que el
    2.26 +\item Para cada fichero del conjunto de cambios que el
    2.27    \texttt{retroceso} afecte, hará el equivalente a
    2.28    \hgcmdargs{revert}{-r parent} sobre ese fichero, para restaurarlo a
    2.29    los contenidos que tenía antes de que el conjunto de cambios fuera
    2.30 @@ -419,7 +419,7 @@
    2.31  vea una discusión de la orden \command{patch} en \ref{sec:mq:patch}).
    2.32  Adicionalmente, la maquinaria de fusión de Mercurial manejará ficheros
    2.33  y directorios renombrados, cambios de permisos, y modificaciones a
    2.34 -archivos binarios, nada de lo cual la orden \command{patch} puede manejar.
    2.35 +ficheros binarios, nada de lo cual la orden \command{patch} puede manejar.
    2.36  
    2.37  \section{Cambios que nunca debieron ocurrir}
    2.38  \label{sec:undo:aaaiiieee}
    2.39 @@ -432,7 +432,7 @@
    2.40  En ocasiones particulares, puede haber consignado un cambio que no
    2.41  debería estar de ninguna forma en el repositorio.  Por ejemplo, sería
    2.42  muy inusual, y considerado como una equivocación, consignar los
    2.43 -archivos objeto junto con el código fuente. los ficheros objeto no
    2.44 +ficheros objeto junto con el código fuente. los ficheros objeto no
    2.45  tienen valor intrínseco y son \emph{grandes}, por lo tanto aumentan el
    2.46  tamaño del repositorio y la cantidad de tiempo que se emplea al clonar
    2.47  o jalar cambios.
    2.48 @@ -540,7 +540,7 @@
    2.49  es útil no solamente para encontrar la fuente de los fallos. Puede
    2.50  usarla para encontrar cualquier ``propiedad emergente'' de un
    2.51  repositorio(Cualquier cosa que usted no pueda encontrar con una
    2.52 -búsqueda de texto sencilla sobre los archivos en el árbol) para la
    2.53 +búsqueda de texto sencilla sobre los ficheros en el árbol) para la
    2.54  cual pueda escribir una prueba binaria.
    2.55  
    2.56  A continuación introduciremos algo terminología, para aclarar qué
    2.57 @@ -594,7 +594,7 @@
    2.58  Simularemos de forma sencilla un proyecto con un fallo: haremos
    2.59  cambios triviales en un ciclo, e indicaremos que un cambio específico
    2.60  sea el ``fallo''.  Este ciclo crea 35 conjuntos de cambios, cada uno
    2.61 -añade un único archivo al repositorio. Representaremos nuestro ``fallo''
    2.62 +añade un único fichero al repositorio. Representaremos nuestro ``fallo''
    2.63  con un fichero que contiene el texto ``tengo un gub''.
    2.64  \interaction{bisect.commits}
    2.65  
    2.66 @@ -624,7 +624,7 @@
    2.67  \interaction{bisect.search.init}
    2.68  
    2.69  En nuestro caso, la prueba binaria es sencilla: revisamos si el
    2.70 -archivo en el repositorio contiene la cadena ``tengo un gub''.  Si la
    2.71 +fichero en el repositorio contiene la cadena ``tengo un gub''.  Si la
    2.72  tiene, este conjunto de cambios contiene aquel que ``causó el fallo''.
    2.73  Por convención, un conjunto de cambios que tiene la propiedad que
    2.74  estamos buscando es ``malo'', mientras que el otro que no la tiene es