1.1 --- a/es/undo.tex	Thu Nov 06 23:06:16 2008 -0500
     1.2 +++ b/es/undo.tex	Thu Nov 06 23:09:47 2008 -0500
     1.3 @@ -205,7 +205,7 @@
     1.4  nuevo nombre, al revertir ambos componentes del renombramiento, cuando
     1.5  Mercurial restaure el fichero que fue eliminado como parte del
     1.6  renombramiento, no será modificado.
     1.7 -Si necesita que las modificaciones en el archivo destino del
     1.8 +Si necesita que las modificaciones en el fichero destino del
     1.9  renombramiento se muestren, no olvide copiarlas encima.)
    1.10  
    1.11  Estos aspectos engorrosos al revertir un renombramiento se constituyen
    1.12 @@ -359,7 +359,7 @@
    1.13  muestra que el tercer camlio es una cabeza separada, \emph{no}
    1.14  esperamos ver el tercer cambio presente en \filename{myfile}.
    1.15  \interaction{backout.manual.cat}
    1.16 -Para que el tercer cambio esté en el archivo, hacemos una fusión usual
    1.17 +Para que el tercer cambio esté en el fichero, hacemos una fusión usual
    1.18  de las dos cabezas.
    1.19  \interaction{backout.manual.merge}
    1.20  Después de eso, la historia gráfica de nuestro repositorio luce como
    1.21 @@ -385,7 +385,7 @@
    1.22    retroceder. Lo llamaremos \texttt{backout}
    1.23  \item Encuentra el padre del conjunto de cambios. Lo llamaremos
    1.24    \texttt{parent}.
    1.25 -\item Para cada archivo del conjunto de cambios que el
    1.26 +\item Para cada fichero del conjunto de cambios que el
    1.27    \texttt{retroceso} afecte, hará el equivalente a
    1.28    \hgcmdargs{revert}{-r parent} sobre ese fichero, para restaurarlo a
    1.29    los contenidos que tenía antes de que el conjunto de cambios fuera
    1.30 @@ -419,7 +419,7 @@
    1.31  vea una discusión de la orden \command{patch} en \ref{sec:mq:patch}).
    1.32  Adicionalmente, la maquinaria de fusión de Mercurial manejará ficheros
    1.33  y directorios renombrados, cambios de permisos, y modificaciones a
    1.34 -archivos binarios, nada de lo cual la orden \command{patch} puede manejar.
    1.35 +ficheros binarios, nada de lo cual la orden \command{patch} puede manejar.
    1.36  
    1.37  \section{Cambios que nunca debieron ocurrir}
    1.38  \label{sec:undo:aaaiiieee}
    1.39 @@ -432,7 +432,7 @@
    1.40  En ocasiones particulares, puede haber consignado un cambio que no
    1.41  debería estar de ninguna forma en el repositorio.  Por ejemplo, sería
    1.42  muy inusual, y considerado como una equivocación, consignar los
    1.43 -archivos objeto junto con el código fuente. los ficheros objeto no
    1.44 +ficheros objeto junto con el código fuente. los ficheros objeto no
    1.45  tienen valor intrínseco y son \emph{grandes}, por lo tanto aumentan el
    1.46  tamaño del repositorio y la cantidad de tiempo que se emplea al clonar
    1.47  o jalar cambios.
    1.48 @@ -540,7 +540,7 @@
    1.49  es útil no solamente para encontrar la fuente de los fallos. Puede
    1.50  usarla para encontrar cualquier ``propiedad emergente'' de un
    1.51  repositorio(Cualquier cosa que usted no pueda encontrar con una
    1.52 -búsqueda de texto sencilla sobre los archivos en el árbol) para la
    1.53 +búsqueda de texto sencilla sobre los ficheros en el árbol) para la
    1.54  cual pueda escribir una prueba binaria.
    1.55  
    1.56  A continuación introduciremos algo terminología, para aclarar qué
    1.57 @@ -594,7 +594,7 @@
    1.58  Simularemos de forma sencilla un proyecto con un fallo: haremos
    1.59  cambios triviales en un ciclo, e indicaremos que un cambio específico
    1.60  sea el ``fallo''.  Este ciclo crea 35 conjuntos de cambios, cada uno
    1.61 -añade un único archivo al repositorio. Representaremos nuestro ``fallo''
    1.62 +añade un único fichero al repositorio. Representaremos nuestro ``fallo''
    1.63  con un fichero que contiene el texto ``tengo un gub''.
    1.64  \interaction{bisect.commits}
    1.65  
    1.66 @@ -624,7 +624,7 @@
    1.67  \interaction{bisect.search.init}
    1.68  
    1.69  En nuestro caso, la prueba binaria es sencilla: revisamos si el
    1.70 -archivo en el repositorio contiene la cadena ``tengo un gub''.  Si la
    1.71 +fichero en el repositorio contiene la cadena ``tengo un gub''.  Si la
    1.72  tiene, este conjunto de cambios contiene aquel que ``causó el fallo''.
    1.73  Por convención, un conjunto de cambios que tiene la propiedad que
    1.74  estamos buscando es ``malo'', mientras que el otro que no la tiene es