# HG changeset patch # User Igor TAmara # Date 1226030987 18000 # Node ID f89ee6f63ea2691e55d35c0eae2f73ed3a9ceca6 # Parent 2a1067c24be1ab4191a9df2e64ab0b336586e981 Archivo to Fichero and update Leame.1st diff -r 2a1067c24be1 -r f89ee6f63ea2 es/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 || || diff -r 2a1067c24be1 -r f89ee6f63ea2 es/undo.tex --- 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