changeset 499:f89ee6f63ea2

Archivo to Fichero and update Leame.1st

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

--- a/es/undo.tex	Thu Nov 06 23:07:42 2008 -0500
+++ b/es/undo.tex	Thu Nov 06 23:09:47 2008 -0500
@@ -205,7 +205,7 @@
 nuevo nombre, al revertir ambos componentes del renombramiento, cuando
 Mercurial restaure el fichero que fue eliminado como parte del
 renombramiento, no será modificado.
-Si necesita que las modificaciones en el archivo destino del
+Si necesita que las modificaciones en el fichero destino del
 renombramiento se muestren, no olvide copiarlas encima.)
 
 Estos aspectos engorrosos al revertir un renombramiento se constituyen
@@ -359,7 +359,7 @@
 muestra que el tercer camlio es una cabeza separada, \emph{no}
 esperamos ver el tercer cambio presente en \filename{myfile}.
 \interaction{backout.manual.cat}
-Para que el tercer cambio esté en el archivo, hacemos una fusión usual
+Para que el tercer cambio esté en el fichero, hacemos una fusión usual
 de las dos cabezas.
 \interaction{backout.manual.merge}
 Después de eso, la historia gráfica de nuestro repositorio luce como
@@ -385,7 +385,7 @@
   retroceder. Lo llamaremos \texttt{backout}
 \item Encuentra el padre del conjunto de cambios. Lo llamaremos
   \texttt{parent}.
-\item Para cada archivo del conjunto de cambios que el
+\item Para cada fichero del conjunto de cambios que el
   \texttt{retroceso} afecte, hará el equivalente a
   \hgcmdargs{revert}{-r parent} sobre ese fichero, para restaurarlo a
   los contenidos que tenía antes de que el conjunto de cambios fuera
@@ -419,7 +419,7 @@
 vea una discusión de la orden \command{patch} en \ref{sec:mq:patch}).
 Adicionalmente, la maquinaria de fusión de Mercurial manejará ficheros
 y directorios renombrados, cambios de permisos, y modificaciones a
-archivos binarios, nada de lo cual la orden \command{patch} puede manejar.
+ficheros binarios, nada de lo cual la orden \command{patch} puede manejar.
 
 \section{Cambios que nunca debieron ocurrir}
 \label{sec:undo:aaaiiieee}
@@ -432,7 +432,7 @@
 En ocasiones particulares, puede haber consignado un cambio que no
 debería estar de ninguna forma en el repositorio.  Por ejemplo, sería
 muy inusual, y considerado como una equivocación, consignar los
-archivos objeto junto con el código fuente. los ficheros objeto no
+ficheros objeto junto con el código fuente. los ficheros objeto no
 tienen valor intrínseco y son \emph{grandes}, por lo tanto aumentan el
 tamaño del repositorio y la cantidad de tiempo que se emplea al clonar
 o jalar cambios.
@@ -540,7 +540,7 @@
 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
-búsqueda de texto sencilla sobre los archivos en el árbol) para la
+búsqueda de texto sencilla sobre los ficheros en el árbol) para la
 cual pueda escribir una prueba binaria.
 
 A continuación introduciremos algo terminología, para aclarar qué
@@ -594,7 +594,7 @@
 Simularemos de forma sencilla un proyecto con un fallo: haremos
 cambios triviales en un ciclo, e indicaremos que un cambio específico
 sea el ``fallo''.  Este ciclo crea 35 conjuntos de cambios, cada uno
-añade un único archivo al repositorio. Representaremos nuestro ``fallo''
+añade un único fichero al repositorio. Representaremos nuestro ``fallo''
 con un fichero que contiene el texto ``tengo un gub''.
 \interaction{bisect.commits}
 
@@ -624,7 +624,7 @@
 \interaction{bisect.search.init}
 
 En nuestro caso, la prueba binaria es sencilla: revisamos si el
-archivo en el repositorio contiene la cadena ``tengo un gub''.  Si la
+fichero en el repositorio contiene la cadena ``tengo un gub''.  Si la
 tiene, este conjunto de cambios contiene aquel que ``causó el fallo''.
 Por convención, un conjunto de cambios que tiene la propiedad que
 estamos buscando es ``malo'', mientras que el otro que no la tiene es