1.1 --- a/es/Leame.1st	Sun Jan 25 11:40:32 2009 -0500
     1.2 +++ b/es/Leame.1st	Sun Jan 25 14:13:45 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  ||      0%    || 25/01/2009 ||             ||
     1.8 +|| branch.tex     || Javier Rojas  ||     90%    || 25/01/2009 ||             ||
     1.9  || preface.tex    ||               ||            ||            ||             ||
    1.10  || daily.tex      || Javier Rojas  ||            ||            ||             ||
    1.11  || tour-basic.tex ||               ||            ||            ||             ||

     2.1 --- a/es/branch.tex	Sun Jan 25 11:40:32 2009 -0500
     2.2 +++ b/es/branch.tex	Sun Jan 25 14:13:45 2009 -0500
     2.3 @@ -14,14 +14,14 @@
     2.4  algunos fallos.
     2.5  
     2.6  En este capítulo, comenzaremos hablando de cómo mantener registro de
     2.7 -las etapas del proyecto como las liberaciones de una
     2.8 +etapas del proyecto como las liberaciones de una
     2.9  versión. Continuaremos hablando del flujo de trabajo entre las
    2.10 -diferentes fases de un proyecto, y como puede ayudar Mercurial a
    2.11 -independizar y administrar tal trabajo.
    2.12 +diferentes fases de un proyecto, y cómo puede ayudar Mercurial a
    2.13 +aislar y administrar tal trabajo.
    2.14  
    2.15  \section{Dar un nombre persistente a una revisión}
    2.16  
    2.17 -Cuando se decide a otorgar a una revisión el nombre particular de una
    2.18 +Cuando usted decide otorgar a una revisión el nombre particular de una
    2.19  ``versión'', es buena idea grabar la identidad de tal revisión.
    2.20  Esto le permitirá reproducir dicha versión en una fecha posterior,
    2.21  para cualquiera que sea el 
    2.22 @@ -48,21 +48,23 @@
    2.23  \item Nueva línea (ASCII 10, ``\Verb+\n+'')
    2.24  \end{itemize}
    2.25  
    2.26 -Puede usar la orden \hgcmd{tags} para observar las etiquetas presentes en
    2.27 +Puede usar la orden \hgcmd{tags} para ver las etiquetas presentes en
    2.28  su repositorio. Al desplegarse, cada revisión marcada se identifica
    2.29 -primero con su nombre, después el número de revisión y finalmente con
    2.30 +primero con su nombre, después con el número de revisión y finalmente con
    2.31  un hash único de la revisión.
    2.32  \interaction{tag.tags}
    2.33 -Note que \texttt{tip} aparece en la lista de \hgcmd{tags}. La etiqueta
    2.34 +Note que \texttt{tip} aparece en en listado generado por \hgcmd{tags}. La etiqueta
    2.35  \texttt{tip} es una etiqueta ``flotante'' especial, que identifica siempre
    2.36 -la revisión más nueva en el repositorio.
    2.37 +la revisión más reciente en el repositorio.
    2.38  
    2.39  Al desplegar la orden \hgcmd{tags}, las etiquetas se listan en orden
    2.40 -inverso, por número de revisión. Lo que significa usualmente que las etiquetas más recientes se listan antes que las más antiguas. También
    2.41 +inverso, por número de revisión. Lo que significa usualmente que las
    2.42 +etiquetas más recientes se listan antes que las más antiguas. También
    2.43  significa que la etiqueta \texttt{tip} siempre aparecerá como primera
    2.44  etiqueta listada al desplegar la orden \hgcmd{tags}.
    2.45  
    2.46 -Cuando ejecuta \hgcmd{log}, se desplegará la revisión que tenga las etiquetas asociadas a ella, se imprimirán tales etiquetas.
    2.47 +Cuando usted ejecuta \hgcmd{log}, si se muestra una revisión que tenga 
    2.48 +etiquetas asociadas a ella, se imprimirán tales etiquetas.
    2.49  \interaction{tag.log}
    2.50  
    2.51  Siempre que requiera indicar un~ID de revisión a una orden de
    2.52 @@ -73,12 +75,12 @@
    2.53  
    2.54  No hay límites en la cantidad de etiquetas por repositorio, o la cantidad
    2.55  de etiquetas que una misma revisión pueda tener. Siendo prácticos, no es
    2.56 -muy buena idea tener ``demasiados'' (la cantidad variará de un
    2.57 +muy buena idea tener ``demasiadas'' (la cantidad variará de un
    2.58  proyecto a otro), debido a que la intención es ayudarle a encontrar
    2.59 -revisiones. Si tiene demasiados tags, la facilidad para identificar
    2.60 -revisiones disminuirá rápidamente.
    2.61 -
    2.62 -Por ejemplo, si su proyecto tiene etapas (milestones) frecuentes en pocos
    2.63 +revisiones. Si tiene demasiadas etiquetas, la facilidad de usarlas
    2.64 +para identificar revisiones disminuirá rápidamente.
    2.65 +
    2.66 +Por ejemplo, si su proyecto tiene etapas (milestones) frecuentes, de pocos
    2.67  días, es perfectamente razonable asignarle una etiqueta a cada una de
    2.68  ellas. Pero si tiene un sistema de construcción automática de binarios
    2.69  que asegura que cada revisión puede generarse limpiamente, estaría
    2.70 @@ -88,34 +90,34 @@
    2.71  llevar cuenta de la posibilidad de generación de binarios.
    2.72  
    2.73  
    2.74 -Si desea eliminar una etiqueta que no desea, use
    2.75 +Si quiere eliminar una etiqueta que no desea, use
    2.76  \hgcmdargs{tag}{--remove}.  
    2.77  \interaction{tag.remove}
    2.78 -También puede modificar una etiqueta en cualquier momento para que
    2.79 -identifique una revisión distinta, basta con aplicar una nueva orden
    2.80 +También puede modificar una etiqueta en cualquier momento, para que
    2.81 +identifique una revisión distinta, simplemente usando una nueva orden
    2.82  \hgcmd{tag}. Deberá usar la opción \hgopt{tag}{-f} para indicarle a
    2.83 -Mercurial que desea actualizar la etiqueta \emph{en serio}.
    2.84 +Mercurial que \emph{realmente} desea actualizar la etiqueta.
    2.85  \interaction{tag.replace}
    2.86  De todas maneras habrá un registro permanente de la antigua identidad
    2.87 -del tag, pero Mercurial no la usará. Por lo tanto no hay castigo al
    2.88 -marcar con una etiqueta una revisión incorrecta; lo único que debe hacer es
    2.89 -mover la etiqueta hacia la revisión correcta tan pronto como localice el
    2.90 -error.
    2.91 +de la etiqueta, pero Mercurial no la usará. Por lo tanto no hay
    2.92 +problema al marcar con una etiqueta una revisión incorrecta; lo único
    2.93 +que debe hacer es mover la etiqueta hacia la revisión correcta tan
    2.94 +pronto como localice el error.
    2.95  
    2.96  Mercurial almacena las etiquetas en un fichero controlado por revisiones en
    2.97  su repositorio. Si ha creado etiquetas, las encontrará en un fichero
    2.98  llamado \sfilename{.hgtags}.  Cuando invoca la orden \hgcmd{tag},
    2.99 -Mercurial modifica este fichero, y automáticamente hace consignación del
   2.100 +Mercurial modifica este fichero, y automáticamente hace la consignación del
   2.101  cambio al mismo.  Esto significa que cada vez que ejecuta \hgcmd{tag},
   2.102 -verá el conjunto de cambios correspondiente en la salida de \hgcmd{log}.
   2.103 +verá un conjunto de cambios correspondiente en la salida de \hgcmd{log}.
   2.104  \interaction{tag.tip}
   2.105  
   2.106  \subsection{Manejo de conflictos entre etiquetas durante una fusión}
   2.107  
   2.108 -Es usual no tener que preocuparse por el fichero \sfilename{.hgtags},
   2.109 -pero aveces hace su aparición durante una fusión. El formato del
   2.110 +Usualmente no tendrá que preocuparse por el fichero \sfilename{.hgtags},
   2.111 +pero a veces hace su aparición durante una fusión. El formato del
   2.112  fichero es sencillo: Consiste de una serie de líneas. Cada línea
   2.113 -comienza con un hash de Conjunto de Cambios, seguido por un espacio,
   2.114 +comienza con un hash de conjunto de cambios, seguido por un espacio,
   2.115  seguido por el nombre de una etiqueta.
   2.116  
   2.117  Si está resolviendo un conflicto en el fichero \sfilename{.hgtags}
   2.118 @@ -126,27 +128,27 @@
   2.119  lee la versión \emph{consignada más reciente} del fichero.
   2.120  
   2.121  Una consecuencia desafortunada de este diseño es que usted no puede
   2.122 -verificar que su fichero \sfilename{.hgtags} fusionado es correcto hasta
   2.123 +verificar que su fichero \sfilename{.hgtags} fusionado sea correcto hasta
   2.124  \emph{después} de haber consignado un cambio. Así que si se
   2.125  encuentra resolviendo un conflicto en \sfilename{.hgtags} durante una
   2.126  fusión, asegúrese de ejecutar la orden \hgcmd{tags} después de
   2.127  consignar. Si encuentra un error en el fichero \sfilename{.hgtags}, 
   2.128 -reportará el lugar del error, que podrá arreglar y después
   2.129 +la orden reportará el lugar del error, que podrá arreglar y después
   2.130  consignar. Posteriormente ejecute de nuevo la orden \hgcmd{tags} para
   2.131 -asegurar que su arreglo fue correctamente aplicado.
   2.132 -
   2.133 -\subsection{Tags y clonado}
   2.134 +asegurarse de que su arreglo fue aplicado correctamente .
   2.135 +
   2.136 +\subsection{Etiquetas y clonado}
   2.137  
   2.138  Puede haber notado que la orden \hgcmd{clone} tiene la opción
   2.139  \hgopt{clone}{-r} que le permite clonar una copia exacta del
   2.140  repositorio hasta un conjunto de cambios específico. El nuevo clon no
   2.141  tendrá historial posterior a la revisión que usted haya
   2.142 -especificado. Esta forma de interactuar puede sorprender a los
   2.143 -desprevenidos.
   2.144 +especificado. Esto tiene una interacción con etiquetas que puede
   2.145 +sorprender a los desprevenidos.
   2.146  
   2.147  Recuerde que una etiqueta se almacena como una revisión al fichero
   2.148 -\sfilename{.hgtags}, consecuente con esto, cuando crea una etiqueta, el
   2.149 -conjunto de cambios en el cual este se almacena necesariamente se
   2.150 +\sfilename{.hgtags}, así que cuando usted crea una etiqueta, el
   2.151 +conjunto de cambios en el cual ésta se almacena necesariamente se
   2.152  refiere a un conjunto de cambios anterior. Cuando ejecuta
   2.153  \hgcmdargs{clone}{-r foo} para clonar un repositorio hasta la etiqueta
   2.154  \texttt{foo}, el nuevo clon \emph{no contendrá el historial que creo
   2.155 @@ -164,13 +166,13 @@
   2.156  tratando de encontrar un fallo sutil, posiblemente desearía colocar una 
   2.157  etiqueta recordándole algo como ``Ana vio los síntomas con esta revisión''.
   2.158  
   2.159 -Para estos casos, lo que posiblemente desearía serían tags
   2.160 +Para estos casos, lo que posiblemente desearía serían etiquetas
   2.161  \emph{locales}. Puede crear una etiqueta local con la opción \hgopt{tag}{-l}
   2.162  de la orden \hgcmd{tag}.  Esto guardará la etiqueta en un fichero llamado
   2.163  \sfilename{.hg/localtags}.  A diferencia de \sfilename{.hgtags},
   2.164  \sfilename{.hg/localtags} no está controlado por revisiones.
   2.165 -Cualquier tag que usted cree usando \hgopt{tag}{-l} se mantendrá
   2.166 -localmente en el repositorio en el que esté trabajando en ese momento.
   2.167 +Cualquier etiqueta que usted cree usando \hgopt{tag}{-l} se mantendrá
   2.168 +localmente al repositorio en el que esté trabajando en ese momento.
   2.169  
   2.170  \section{El flujo de cambios---El gran cuadro vs. el pequeño}
   2.171  
   2.172 @@ -178,14 +180,14 @@
   2.173  hecho de que un proyecto tiene muchas piezas concurrentes de trabajo
   2.174  en desarrollo al mismo tiempo.
   2.175  
   2.176 -Puede haber prisa por una nueva versión ``principal''; Un nueva
   2.177 +Puede haber prisa por una nueva versión ``principal''; una nueva
   2.178  versión con un arreglo de fallo a la última versión; y una versión de
   2.179  ``mantenimiento correctivo'' a una versión antigua que ha entrado en
   2.180  modo de mantenimiento.
   2.181  
   2.182  Usualmente la gente se refiere a esas direcciones
   2.183 -concurrentes de desarrollo es como ``ramas''.  Aunque hemos visto que
   2.184 -en variadas ocasiones Mercurial trata a \emph{toda el historial} como
   2.185 +concurrentes de desarrollo como ``ramas''.  Sin embargo, ya hemos visto que
   2.186 +en varias ocasiones Mercurial trata a \emph{todo el historial} como
   2.187  una serie de ramas y fusiones.  Realmente lo que tenemos aquí es dos
   2.188  ideas que se relacionan periféricamente, pero que en esencia comparten
   2.189  un nombre.
   2.190 @@ -194,7 +196,7 @@
   2.191    evolución del proyecto; la gente les da nombres y hablan acerca de
   2.192    ellas en sus conversaciones.
   2.193  \item ``El cuadro pequeño'' Las ramas son artefactos de las
   2.194 -  actividades diarias de al desarrollar y fusionar cambios. Exponen la
   2.195 +  actividades diarias de desarrollar y fusionar cambios. Exponen la
   2.196    narrativa de cómo se desarrolló el código.
   2.197  \end{itemize}
   2.198  
   2.199 @@ -205,19 +207,19 @@
   2.200  repositorio compartido existente ---llamémoslo
   2.201  \texttt{myproject}---que alcanzó la etapa ``1.0'', puede comenzar a
   2.202  prepararse para versiones de mantenimiento futuras a partir de la
   2.203 -versión~1.0 marcando con una etiqueta en la revisión con la cual preparó la versión~1.0.
   2.204 +versión~1.0 marcando con una etiqueta la revisión con la cual preparó la versión~1.0.
   2.205  \interaction{branch-repo.tag}
   2.206  Ahora puede clonar un repositorio compartido nuevo
   2.207 -\texttt{myproject-1.0.1} con tal tag.
   2.208 +\texttt{myproject-1.0.1} con tal etiqueta.
   2.209  \interaction{branch-repo.clone}
   2.210  
   2.211  Posteriormente, si alguien necesita trabajar en la reparación de un
   2.212  fallo debería dirigirse a la liberación de versión~1.0.1 que viene en
   2.213  camino, ellos clonarían el repositorio \texttt{myproject-1.0.1},
   2.214 -harían sus cambios y los publicarían (con push).
   2.215 +harían sus cambios y los empujarían de vuelta.
   2.216  \interaction{branch-repo.bugfix}
   2.217  Mientras tanto, el desarrollo para la siguiente versión mayor puede
   2.218 -continuar aislada e incólume, en el repositorio \texttt{myproject}.
   2.219 +continuar aislado e incólume, en el repositorio \texttt{myproject}.
   2.220  \interaction{branch-repo.new}
   2.221  
   2.222  \section{No repita trabajo: fusión entre ramas}
   2.223 @@ -233,7 +235,7 @@
   2.224  En el caso más sencillo, basta con jalar los cambios de la rama de
   2.225  mantenimiento a la rama objetivo en su clon local.
   2.226  \interaction{branch-repo.pull}
   2.227 -A continuación deberá mezclar las cabezas de las dos ramas, y publicar
   2.228 +A continuación deberá mezclar las cabezas de las dos ramas, y empujar
   2.229  de nuevo a la rama principal.
   2.230  \interaction{branch-repo.merge}
   2.231  
   2.232 @@ -241,10 +243,10 @@
   2.233  
   2.234  La aproximación correcta en casi todas las oportunidades es aislar las
   2.235  ramas en los repositorios.  Es fácil de entender gracias a su
   2.236 -facilidad; y es difícil cometer errores. Hay una relación uno a uno
   2.237 +simplicidad; y es difícil cometer errores. Hay una relación uno a uno
   2.238  entre las ramas y los directorios con los que está trabajando en su
   2.239 -sistema. Esto le permite usar emplear herramientas usuales (para los
   2.240 -nuevos a Mercurial) para trabajar con los ficheros dentro de su
   2.241 +sistema. Esto le permite usar emplear herramientas usuales (que no son
   2.242 +conscientes de Mercurial) para trabajar con los ficheros dentro de una
   2.243  rama/repositorio.
   2.244  
   2.245  Si se encuentra más en la categoría ``usuario diestro'' (\emph{y} sus
   2.246 @@ -268,16 +270,16 @@
   2.247  está indicando que su consignación ocurrirá en la rama llamada 
   2.248  \texttt{default}.
   2.249  
   2.250 -Use la orden \hgcmd{branches} para comenzar a trabajar con ramas
   2.251 +Use la orden \hgcmd{branches} para empezar a trabajar con ramas
   2.252  nombradas. Esta orden mostrará las ramas presentes en su repositorio,
   2.253 -indicándole en qué conjunto de cambios está cada una.
   2.254 +indicándole qué conjunto de cambios es la punta de cada una.
   2.255  \interaction{branch-named.branches}
   2.256 -Dado que todavía no ha creado ramas nombradas, la única que verá sería
   2.257 +Dado que todavía no ha creado ramas nombradas, la única que verá será
   2.258  \texttt{default}.
   2.259  
   2.260  Para hallar cuál es la rama ``actual'', invoque la orden
   2.261  \hgcmd{branch}, sin argumento alguno. Le informará en qué rama se
   2.262 -encuentra el padre del conjunto actual de cambios.
   2.263 +encuentra el padre del conjunto de cambios actual.
   2.264  \interaction{branch-named.branch}
   2.265  
   2.266  Para crear una nueva rama, invoque la orden \hgcmd{branch} de
   2.267 @@ -287,7 +289,7 @@
   2.268  
   2.269  Después de crear la rama, usted podría desear ver el efecto que tuvo
   2.270  la orden \hgcmd{branch}.  ¿Qué reportan las ordenes \hgcmd{status} y
   2.271 -\hgcmd{tip} commands report?
   2.272 +\hgcmd{tip}?
   2.273  \interaction{branch-named.status}
   2.274  Nada cambia en el directorio actual, y no se ha añadido nada al
   2.275  historial. Esto sugiere que al ejecutar la orden \hgcmd{branch} no hay
   2.276 @@ -301,7 +303,7 @@
   2.277  desplieguen la misma clase de información.
   2.278  \interaction{branch-named.commit}
   2.279  Las órdenes del tipo \hgcmd{log} imprimirán el nombre de la rama de
   2.280 -cualquier conjunto de cambios que no estén en la rama
   2.281 +cualquier conjunto de cambios que no esté en la rama
   2.282  \texttt{default}. Como resultado, si nunca usa ramas nombradas, nunca
   2.283  verá esta información.
   2.284  
   2.285 @@ -319,12 +321,12 @@
   2.286  Si tiene más de una rama nombrada en un repositorio, Mercurial
   2.287  recordará la rama en la cual está su directorio de trabajo cuando
   2.288  invoque una orden como \hgcmd{update} o \hgcmdargs{pull}{-u}.  Se
   2.289 -actualizará su directorio de trabajo actual al tip de esta rama, sin
   2.290 -importar cuál sea el tip ``a lo largo del repositorio''.  Para
   2.291 +actualizará su directorio de trabajo actual a la punta de esta rama, sin
   2.292 +importar cuál sea la punta ``a lo largo del repositorio''.  Para
   2.293  actualizar a una revisión que está en una rama con distinto nombre,
   2.294  puede necesitar la opción \hgopt{update}{-C} de \hgcmd{update}.
   2.295  
   2.296 -Este comportamiento puede ser sutil, veámoslo en acción.  Primero,
   2.297 +Este comportamiento puede ser sutil, así que veámoslo en acción.  Primero,
   2.298  recordemos en qué rama estamos trabajando, y qué ramas están en
   2.299  nuestro repositorio.
   2.300  \interaction{branch-named.parents}
   2.301 @@ -338,7 +340,7 @@
   2.302  \interaction{branch-named.update-switchy}
   2.303  
   2.304  Si volvemos a la rama \texttt{foo} e invocamos la orden \hgcmd{update},
   2.305 -nos mantendrá en \texttt{foo}, sin movernos al tipo de \texttt{bar}.
   2.306 +nos mantendrá en \texttt{foo}, sin movernos a la punta de \texttt{bar}.
   2.307  \interaction{branch-named.update-nothing}
   2.308  
   2.309  Al consignar un cambio a la rama \texttt{foo} se introducirá una nueva