hgbook

changeset 531:d2b1369e58d0

passed the file through spell check

also corrected a couple of redaction problems
author Javier Rojas <jerojasro@devnull.li>
date Sun Jan 25 11:40:32 2009 -0500 (2009-01-25)
parents 04977ab515f6
children f7a2c5959d48
files es/Leame.1st es/branch.tex
line diff
     1.1 --- a/es/Leame.1st	Tue Jan 20 11:44:09 2009 -0500
     1.2 +++ b/es/Leame.1st	Sun Jan 25 11:40:32 2009 -0500
     1.3 @@ -118,7 +118,7 @@
     1.4  == Archivos en proceso de revisión ==
     1.5  ||'''archivo'''   || '''revisor''' ||'''Estado'''||'''Inicio'''||  '''Fin'''  ||
     1.6  || 00book.tex     || Javier Rojas  ||    100%    || 18/01/2009 ||  18/01/2009 ||
     1.7 -|| branch.tex     || Javier Rojas  ||            ||            ||             ||
     1.8 +|| branch.tex     || Javier Rojas  ||      0%    || 25/01/2009 ||             ||
     1.9  || preface.tex    ||               ||            ||            ||             ||
    1.10  || daily.tex      || Javier Rojas  ||            ||            ||             ||
    1.11  || tour-basic.tex ||               ||            ||            ||             ||
     2.1 --- a/es/branch.tex	Tue Jan 20 11:44:09 2009 -0500
     2.2 +++ b/es/branch.tex	Sun Jan 25 11:40:32 2009 -0500
     2.3 @@ -2,7 +2,7 @@
     2.4  \chapter{Administración de versiones y desarrollo ramificado}
     2.5  \label{chap:branch}
     2.6  
     2.7 -Mercurial ofrece varios mecanismos que le permitirán administrar un
     2.8 +Mercurial ofrece varios mecanismos que le permiten administrar un
     2.9  proyecto que avanza en múltiples frentes simultáneamente. Para
    2.10  entender estos mecanismos, demos un vistazo a la estructura usual de
    2.11  un proyecto de software.
    2.12 @@ -62,16 +62,16 @@
    2.13  significa que la etiqueta \texttt{tip} siempre aparecerá como primera
    2.14  etiqueta listada al desplegar la orden \hgcmd{tags}.
    2.15  
    2.16 -Cuando ejecuta \hgcmd{log}, se desplegará la revisión que tenga las etiquetas asociados a ella, se imprimirán tales etiquetas.
    2.17 +Cuando ejecuta \hgcmd{log}, se desplegará la revisión que tenga las etiquetas asociadas a ella, se imprimirán tales etiquetas.
    2.18  \interaction{tag.log}
    2.19  
    2.20 -Siempre que requiera indicar un ~ID de revisión a una orden de
    2.21 +Siempre que requiera indicar un~ID de revisión a una orden de
    2.22  Mercurial, aceptará un nombre de etiqueta en su lugar.  Internamente,
    2.23 -Mercurial traducirá su nombre de etiqueta en el ~ID de revisión
    2.24 +Mercurial traducirá su nombre de etiqueta en el~ID de revisión
    2.25  correspondiente, y lo usará.
    2.26  \interaction{tag.log.v1.0}
    2.27  
    2.28 -No hay límites en la cantidad de etiquetas por reposirorio, o la cantidad
    2.29 +No hay límites en la cantidad de etiquetas por repositorio, o la cantidad
    2.30  de etiquetas que una misma revisión pueda tener. Siendo prácticos, no es
    2.31  muy buena idea tener ``demasiados'' (la cantidad variará de un
    2.32  proyecto a otro), debido a que la intención es ayudarle a encontrar
    2.33 @@ -121,13 +121,13 @@
    2.34  Si está resolviendo un conflicto en el fichero \sfilename{.hgtags}
    2.35  durante una fusión, hay un detalle para tener en cuenta al modificar
    2.36  el fichero \sfilename{.hgtags}:
    2.37 -cuando Mercurial parsea las etiquetas en el repositorio \emph{nunca}
    2.38 +cuando Mercurial procesa las etiquetas en el repositorio \emph{nunca}
    2.39  lee la copia de trabajo del fichero \sfilename{.hgtags}.  En cambio,
    2.40  lee la versión \emph{consignada más reciente} del fichero.
    2.41  
    2.42  Una consecuencia desafortunada de este diseño es que usted no puede
    2.43  verificar que su fichero \sfilename{.hgtags} fusionado es correcto hasta
    2.44 -\emph{después} de haber consignado (hecho commit). Así que si se
    2.45 +\emph{después} de haber consignado un cambio. Así que si se
    2.46  encuentra resolviendo un conflicto en \sfilename{.hgtags} durante una
    2.47  fusión, asegúrese de ejecutar la orden \hgcmd{tags} después de
    2.48  consignar. Si encuentra un error en el fichero \sfilename{.hgtags}, 
    2.49 @@ -161,7 +161,7 @@
    2.50  verán las etiquetas que usted haya creado. El hecho de dar nombres a las
    2.51  revisiones tiene usos más allá que simplemente hacer notar que la
    2.52  revisión \texttt{4237e45506ee} es realmente \texttt{v2.0.2}.  Si está
    2.53 -tratando de encontrar un bug sutil, posiblemente desearía colocar una 
    2.54 +tratando de encontrar un fallo sutil, posiblemente desearía colocar una 
    2.55  etiqueta recordándole algo como ``Ana vio los síntomas con esta revisión''.
    2.56  
    2.57  Para estos casos, lo que posiblemente desearía serían tags
    2.58 @@ -179,7 +179,7 @@
    2.59  en desarrollo al mismo tiempo.
    2.60  
    2.61  Puede haber prisa por una nueva versión ``principal''; Un nueva
    2.62 -versión con un rreglo de fallo a la última versión; y una versión de
    2.63 +versión con un arreglo de fallo a la última versión; y una versión de
    2.64  ``mantenimiento correctivo'' a una versión antigua que ha entrado en
    2.65  modo de mantenimiento.
    2.66  
    2.67 @@ -217,7 +217,7 @@
    2.68  harían sus cambios y los publicarían (con push).
    2.69  \interaction{branch-repo.bugfix}
    2.70  Mientras tanto, el desarrollo para la siguiente versión mayor puede
    2.71 -continuar asilada e incólume, en el repositorio \texttt{myproject}.
    2.72 +continuar aislada e incólume, en el repositorio \texttt{myproject}.
    2.73  \interaction{branch-repo.new}
    2.74  
    2.75  \section{No repita trabajo: fusión entre ramas}
    2.76 @@ -231,7 +231,7 @@
    2.77  sin duplicar su trabajo.
    2.78  
    2.79  En el caso más sencillo, basta con jalar los cambios de la rama de
    2.80 -mantenimiento a la rama obetivo en su clon local.
    2.81 +mantenimiento a la rama objetivo en su clon local.
    2.82  \interaction{branch-repo.pull}
    2.83  A continuación deberá mezclar las cabezas de las dos ramas, y publicar
    2.84  de nuevo a la rama principal.
    2.85 @@ -249,7 +249,7 @@
    2.86  
    2.87  Si se encuentra más en la categoría ``usuario diestro'' (\emph{y} sus
    2.88  colaboradores también), puede considerar otra alternativa para
    2.89 -administrar las ramas. He mencionador con anterioridad la distinción a
    2.90 +administrar las ramas. He mencionado con anterioridad la distinción a
    2.91  nivel humano entre las ramas estilo ``cuadro pequeño'' y ``gran
    2.92  cuadro''.  Mientras que Mercurial trabaja con muchas ramas del estilo
    2.93  ``cuadro pequeño'' en el repositorio todo el tiempo (por ejemplo cuando
    2.94 @@ -294,7 +294,7 @@
    2.95  un efecto permanente; solamente le indica a que nombre de rama usará
    2.96  la \emph{próxima} vez que consigne un conjunto de cambios.
    2.97  
    2.98 -Cuando consigna un cambio, Mercurial alamacena el nombre de la rama en
    2.99 +Cuando consigna un cambio, Mercurial almacena el nombre de la rama en
   2.100  la cual consignó.  Una vez que haya cambiado de la rama \texttt{default}
   2.101  y haya consignado, verá que el nombre de la nueva rama se mostrará
   2.102  cuando use la orden \hgcmd{log}, \hgcmd{tip}, y otras órdenes que
   2.103 @@ -321,7 +321,7 @@
   2.104  invoque una orden como \hgcmd{update} o \hgcmdargs{pull}{-u}.  Se
   2.105  actualizará su directorio de trabajo actual al tip de esta rama, sin
   2.106  importar cuál sea el tip ``a lo largo del repositorio''.  Para
   2.107 -actualiar a una revisión que está en una rama con distinto nombre,
   2.108 +actualizar a una revisión que está en una rama con distinto nombre,
   2.109  puede necesitar la opción \hgopt{update}{-C} de \hgcmd{update}.
   2.110  
   2.111  Este comportamiento puede ser sutil, veámoslo en acción.  Primero,
   2.112 @@ -348,13 +348,13 @@
   2.113  \section{Nombres de ramas y fusiones}
   2.114  
   2.115  Posiblemente ha notado que las fusiones en Mercurial no son simétricas.
   2.116 -Supongamos que su repositorio tiene dos cabezas, 17 and 23.  Si yo invoco
   2.117 +Supongamos que su repositorio tiene dos cabezas, 17 y 23.  Si yo invoco
   2.118  \hgcmd{update} a 17 y aplico \hgcmd{merge} a 23, Mercurial almacena 17
   2.119  como el primer padre de la fusión, y 23 como el segundo. Mientras que
   2.120  si hago \hgcmd{update} a 23 y después aplico \hgcmd{merge} con 17,
   2.121  grabará a 23 como el primer padre, y 17 como el segundo.
   2.122  
   2.123 -Esto afecta com elige Mercurial el nombre de la rama cuando hace
   2.124 +Esto afecta el cómo elige Mercurial el nombre de la rama cuando hace
   2.125  fusión.  Después de una fusión Mercurial mantendrá el nombre de la
   2.126  rama del primer padre cuando consigne el resultado de una fusión.  Si
   2.127  el primer nombre de su padre es \texttt{foo}, y fusiona con
   2.128 @@ -373,7 +373,7 @@
   2.129  \texttt{bar}.
   2.130  \interaction{branch-named.merge}
   2.131  
   2.132 -En un ejemplo más concreo, si yo estoy trabajando en la rama
   2.133 +En un ejemplo más concreto, si yo estoy trabajando en la rama
   2.134  \texttt{bleeding-edge}, y deseo traer los arreglos más recientes de la
   2.135  rama \texttt{estable}, Mercurial elegirá el nombre de rama ``correcto''
   2.136  (\texttt{bleeding-edge}) cuando yo jale una fusión desde \texttt{estable}.