hgbook

changeset 378:6d2bbeb50af6

Fixing mistake preventing from build, footnote to ndt, moving archivo to fichero on daily.tex
author Igor TAmara <igor@tamarapatino.org>
date Mon Oct 27 23:49:04 2008 -0500 (2008-10-27)
parents d5f1049a79dd
children dbc78b312fc0
files es/daily.tex es/undo.tex
line diff
     1.1 --- a/es/daily.tex	Mon Oct 27 17:14:02 2008 -0500
     1.2 +++ b/es/daily.tex	Mon Oct 27 23:49:04 2008 -0500
     1.3 @@ -169,33 +169,33 @@
     1.4  
     1.5  Mercurial ofrece la orden \hgcmd{copy} para hacer una nueva copia de
     1.6  un fichero.  Cuando se copia un fichero con esta orden, Mercurial
     1.7 -lleva un registro indicando que el nuevo archivo es una copia del
     1.8 +lleva un registro indicando que el nuevo fichero es una copia del
     1.9  fichero original. Trata de forma especial los ficheros copiados cuando
    1.10  usted hace una fusión con el trabajo de alguien más.
    1.11  
    1.12 -\subsection{Resultados de copiar un archivo durante una fusión}
    1.13 +\subsection{Resultados de copiar un fichero durante una fusión}
    1.14  
    1.15  Durante una fusión lols cambios ``siguen'' una copia.  Para ilustrar
    1.16  lo que esto significa, haremos un ejemplo.  Comenzaremos con el mini
    1.17 -repositorio usual que contiene un solo archivo
    1.18 +repositorio usual que contiene un solo fichero
    1.19  \interaction{daily.copy.init}
    1.20  Debemos trabajar algo en paralelo, de forma que tengamos algo para
    1.21  fusionar. Aquí clonamos el repositorio.
    1.22  \interaction{daily.copy.clone}
    1.23  De vuelta en el repositorio, usemos la orden \hgcmd{copy} para hacer
    1.24 -una copia del primer archivo que creamos.
    1.25 +una copia del primer fichero que creamos.
    1.26  \interaction{daily.copy.copy}
    1.27  
    1.28 -Si vemos la salida de la orden \hgcmd{status}, el archivo copiado luce
    1.29 -como un archivo que se ha añadido normalmente.
    1.30 +Si vemos la salida de la orden \hgcmd{status}, el fichero copiado luce
    1.31 +como un fichero que se ha añadido normalmente.
    1.32  \interaction{daily.copy.status}
    1.33  Si usamos la opción \hgopt{status}{-C} de la orden \hgcmd{status},
    1.34 -imprimirá otra línea: Ela archivo of output: this is the file that our newly-added
    1.35 +imprimirá otra línea: Ela fichero of output: this is the file that our newly-added
    1.36  file was copied \emph{from}.
    1.37  \interaction{daily.copy.status-copy}
    1.38  
    1.39  Ahora, en el repositorio que clonamos, hagamos un cambio en
    1.40 -paralelo. Adicionaremos una línea de contenido al archivo original que
    1.41 +paralelo. Adicionaremos una línea de contenido al fichero original que
    1.42  creamos.
    1.43  \interaction{daily.copy.other}
    1.44  Hemos modificado el fichero \filename{file} en este
    1.45 @@ -212,7 +212,7 @@
    1.46  casos es absolutamente deseable.
    1.47  
    1.48  Es indispensable recordar que esta propagación \emph{solamente} sucede
    1.49 -cuando fusionamos.  Por lo tanto si sobre un archivo se usa
    1.50 +cuando fusionamos.  Por lo tanto si sobre un fichero se usa
    1.51  \hgcmd{copy}, y se modifica el fichero original durante el curso
    1.52  normal de su trabajo, nada pasará.
    1.53  
    1.54 @@ -222,15 +222,15 @@
    1.55  
    1.56  Explicaremos a continuación la razón de este comportamiento de
    1.57  Mercurial. Digamos que yo he aplicado un arreglo de un fallo importante a un
    1.58 -archivo fuente y consigné los cambios.  Por otro lado, usted decidió hacer
    1.59 +fichero fuente y consigné los cambios.  Por otro lado, usted decidió hacer
    1.60  \hgcmd{copy} sobre el fichero en su repositorio, sin saber acerca del
    1.61  fallo o sin ver el arreglo, y ha comenzado a trabajar sobre su copia
    1.62 -del archivo.
    1.63 +del fichero.
    1.64  
    1.65  Si jala y fusiona mis cambios y Mercurial \emph{no hubiera} propagado
    1.66  los cambios en las copias, su fichero fuente tendría el fallo, a menos
    1.67  que usted haya recordado propagar el arreglo del fallo a mano, el
    1.68 -mismo \emph{permanecería} en su copia del archivo.
    1.69 +mismo \emph{permanecería} en su copia del fichero.
    1.70  
    1.71  Mercurial previene esta clase de problemas, gracias a la propagación
    1.72  automática del cambio que arregló el fallo del fichero original. Hasta
    1.73 @@ -257,7 +257,7 @@
    1.74  \subsection{Comportamiento de la orden \hgcmd{copy}}
    1.75  
    1.76  Cuando usa la orden \hgcmd{copy}, Mercurial hace una copia de cada
    1.77 -archivo fuente del directorio actual. Esto significa que si usted hace
    1.78 +fichero fuente del directorio actual. Esto significa que si usted hace
    1.79  modificaciones a un fichero, y le aplica \hgcmd{copy} sin haber
    1.80  consignado primero los cambios, la nueva copia contendrá también las
    1.81  modificaciones que haya hecho hasta ese punto. (Este comportamiento me
    1.82 @@ -289,19 +289,19 @@
    1.83  La necesidad de renombrar un fichero es más común que hacer una copia
    1.84  del fichero.  La razón por la cual discutí la orden \hgcmd{copy} antes
    1.85  de hablar acerca de cambiar el nombre de los ficheros, es que
    1.86 -Mercurial trata el renombrar un archivo de la misma forma que una
    1.87 +Mercurial trata el renombrar un fichero de la misma forma que una
    1.88  copia.  Por lo tanto, saber lo que hace Mercurial cuando usted copia
    1.89 -un archivo, le indica qué esperar cuando renombra un archivo.
    1.90 +un fichero, le indica qué esperar cuando renombra un fichero.
    1.91  
    1.92  Cuando usa la orden \hgcmd{rename}, Mercurial hace una copia de cada
    1.93 -archivo fuente, lo borra y lo marca como fichero eliminado.
    1.94 +fichero fuente, lo borra y lo marca como fichero eliminado.
    1.95  \interaction{daily.rename.rename}
    1.96  La orden \hgcmd{status} muestra la nueva copia del fichero como
    1.97  añadido y el fichero inicial de la copia, como eliminado.
    1.98  \interaction{daily.rename.status}
    1.99  De la misma forma como se usa la orden \hgcmd{copy}, debemos usar la
   1.100  opción \hgopt{status}{-C} de la orden \hgcmd{status} para verificar
   1.101 -que el archivo añadido realmente comienza a  ser seguido por Mercurial
   1.102 +que el fichero añadido realmente comienza a  ser seguido por Mercurial
   1.103  como una copia del fichero original, ahora eliminado.
   1.104  \interaction{daily.rename.status-copy}
   1.105  
   1.106 @@ -317,7 +317,7 @@
   1.107  copiar-y-eliminar, la misma propagación de cambios ocurre cuando usted
   1.108  fusiona después de renombrar como después de hacer una copia.
   1.109  
   1.110 -Si Yo modifico un fichero y usted lo renombra a un nuevo archivo, y
   1.111 +Si Yo modifico un fichero y usted lo renombra a un nuevo fichero, y
   1.112  posteriormente fusionamos nuestros cambios respectivos, mi
   1.113  modificación al fichero bajo su nombre original se propagará en el
   1.114  fichero con el nuevo nombre. (Es lo que se esperaría como ``lo hace,''
   1.115 @@ -327,7 +327,7 @@
   1.116  puede subestimar diciendo ``si, puede ser útil,'' debería ser claro
   1.117  que el seguimiento de cambios de un renombramiento es importante
   1.118  definitivamente.  Sin esto, sería muy sencillo que los cambios se
   1.119 -volvieran huérfanos cuando los archivos se renombran.
   1.120 +volvieran huérfanos cuando los ficheros se renombran.
   1.121  
   1.122  \subsection{Cambios de nombre divergentes y fusión}
   1.123  
   1.124 @@ -365,7 +365,7 @@
   1.125  \subsection{Otros casos límites relacionados con renombramientos}
   1.126  
   1.127  Mercurial tiene un fallo de mucho tiempo en el cual no es capaz de
   1.128 -fusionar cuando por un lado hay un archivo con un nombre dado,
   1.129 +fusionar cuando por un lado hay un fichero con un nombre dado,
   1.130  mientras que en otro hay un directorio con el mismo nombre. Esto está
   1.131  documentado como~\bug{29}.
   1.132  \interaction{issue29.go}
   1.133 @@ -378,7 +378,7 @@
   1.134  La orden \hgcmd{revert} le permite deshacer cambios que haya hecho a
   1.135  su directorio de trabajo. Por ejemplo, Si aplicó \hgcmd{add} a un
   1.136  fichero por accidente, ejecute \hgcmd{revert} con el nombre del
   1.137 -fichero que añadió, y en tando que el archivo no haya sido tocado de
   1.138 +fichero que añadió, y en tando que el fichero no haya sido tocado de
   1.139  forma alguna, no será adicionado, ni seguido por Mercurial.  También
   1.140  puede usar \hgcmd{revert} para deshacerse de cambios erróneos a un
   1.141  fichero.
     2.1 --- a/es/undo.tex	Mon Oct 27 17:14:02 2008 -0500
     2.2 +++ b/es/undo.tex	Mon Oct 27 23:49:04 2008 -0500
     2.3 @@ -15,20 +15,20 @@
     2.4  Tengo el problema ocasional, pero persistente de teclear más rápido de
     2.5  lo que pienso, que aveces resulta en consignar un conjunto de cambios
     2.6  incompleto o simplemente malo. En mi caso, el conjunto de cambios
     2.7 -incompleto consiste en que creé un nuevo archivo fuente, pero olvidé
     2.8 +incompleto consiste en que creé un nuevo fichero fuente, pero olvidé
     2.9  hacerle \hgcmd{add}.  Un conjunto de cambios``simplemente malo'' no es
    2.10  tan común, pero sí resulta muy molesto.
    2.11  
    2.12 -\subsection{Hacer rollback\footnote{El significado igual que en los
    2.13 -    ambientes de sistemas manejadores de bases de datos se refiere a
    2.14 -    la atomicidad e integridad al devolver un conjunto de acciones que
    2.15 -  permitan dejar el repositorio en un estado consistente previo} una transacción}
    2.16 +\subsection{Hacer rollback una transacción}
    2.17  \label{sec:undo:rollback}
    2.18  
    2.19  En la sección~\ref{sec:concepts:txn}, mencioné que Mercurial trata
    2.20  modificación a un repositorio como una \emph{transacción}.  Cada vez
    2.21  que consigna un conjunto de cambios o lo jala de otro repositorio,
    2.22 -Mercurial recuerda lo que hizo.  Puede deshacer, o hacer \emph{roll back},
    2.23 +Mercurial recuerda lo que hizo.  Puede deshacer, o hacer \emph{roll back}\ndt{El significado igual que en los
    2.24 +    ambientes de sistemas manejadores de bases de datos se refiere a
    2.25 +    la atomicidad e integridad al devolver un conjunto de acciones que
    2.26 +  permitan dejar el repositorio en un estado consistente previo},
    2.27  exactamente una de tales acciones usando la orden \hgcmd{rollback}.
    2.28  (Ver en la sección~\ref{sec:undo:rollback-after-push} una anotación
    2.29  importante acerca del uso de esta orden.)
    2.30 @@ -40,7 +40,7 @@
    2.31  La salida de \hgcmd{status} después de la consignación confirma
    2.32  inmediatamente este error.
    2.33  \interaction{rollback.status}
    2.34 -La consignación capturó los cambios en el archivo \filename{a}, pero
    2.35 +La consignación capturó los cambios en el fichero \filename{a}, pero
    2.36  no el nuevo fichero \filename{b}.  Si yo publicara este conjunto de
    2.37  cambios a un repositorio compartido con un colega, es bastante
    2.38  probable que algo en \filename{a} se refiriera a \filename{b}, el cual