1.1 --- a/es/Leame.1st	Sun Jan 18 19:45:33 2009 -0500
     1.2 +++ b/es/Leame.1st	Sun Jan 18 21:01:13 2009 -0500
     1.3 @@ -117,7 +117,7 @@
     1.4  
     1.5  == Archivos en proceso de revisión ==
     1.6  ||'''archivo'''   || '''revisor''' ||'''Estado'''||'''Inicio'''||  '''Fin'''  ||
     1.7 -|| 00book.tex     || Javier Rojas  ||            ||            ||             ||
     1.8 +|| 00book.tex     || Javier Rojas  ||    100%    || 18/01/2009 ||  18/01/2009 ||
     1.9  || branch.tex     || Javier Rojas  ||            ||            ||             ||
    1.10  || preface.tex    ||               ||            ||            ||             ||
    1.11  || daily.tex      || Javier Rojas  ||            ||            ||             ||

     2.1 --- a/es/branch.tex	Sun Jan 18 19:45:33 2009 -0500
     2.2 +++ b/es/branch.tex	Sun Jan 18 21:01:13 2009 -0500
     2.3 @@ -1,4 +1,5 @@
     2.4 -\chapter{Administración de Versiones y desarrollo ramificado}
     2.5 +%% vim: tw=70 encoding=utf8
     2.6 +\chapter{Administración de versiones y desarrollo ramificado}
     2.7  \label{chap:branch}
     2.8  
     2.9  Mercurial ofrece varios mecanismos que le permitirán administrar un
    2.10 @@ -6,10 +7,10 @@
    2.11  entender estos mecanismos, demos un vistazo a la estructura usual de
    2.12  un proyecto de software.
    2.13  
    2.14 -Muchos proyectos de software liberan una versión``mayor'' que contiene
    2.15 +Muchos proyectos de software liberan una versión ``mayor'' que contiene
    2.16  nuevas características substanciales.  En paralelo, pueden liberar
    2.17 -versiones ``menores''.   Estas usualmente son idénticas a las
    2.18 -versiones mayores en las cuales están basadas, pero con arreglo de
    2.19 +versiones ``menores''.   Usualmente éstas son idénticas a las
    2.20 +versiones mayores en las cuales están basadas, pero con arreglos para
    2.21  algunos fallos.
    2.22  
    2.23  En este capítulo, comenzaremos hablando de cómo mantener registro de
    2.24 @@ -21,32 +22,33 @@
    2.25  \section{Dar un nombre persistente a una revisión}
    2.26  
    2.27  Cuando se decide a otorgar a una revisión el nombre particular de una
    2.28 -``versión'', es buena idea grabar la identidad para tal revisión.
    2.29 -Lo cual permitirá reproducir tal versión en una fecha posterior, o el
    2.30 -propósito que se considere en ese momento (reproducir un fallo, portar
    2.31 +``versión'', es buena idea grabar la identidad de tal revisión.
    2.32 +Esto le permitirá reproducir dicha versión en una fecha posterior,
    2.33 +para cualquiera que sea el 
    2.34 +propósito que se tenga en ese momento (reproducir un fallo, portar
    2.35  a una nueva plataforma, etc).
    2.36  \interaction{tag.init}
    2.37  
    2.38  Mercurial le permite dar un nombre permanente a cualquier revisión
    2.39  usando la orden \hgcmd{tag}.  Sin causa de sorpresa, esos nombres se llaman
    2.40 -``tags''(etiquetas).
    2.41 +``tags'' (etiquetas).
    2.42  \interaction{tag.tag}
    2.43  
    2.44 -Un tag no es más que un ``nombre simbólico'' para una revisión.  Los
    2.45 -tags existen únicamente para su conveniencia, dotándolo de una forma
    2.46 -permanente y sencilla para referirse a una revisión; Mercurial no
    2.47 -interpreta de ninguna manera los nombres de los tags que usted use.
    2.48 -Mercurial tampoco impone restricción alguna al nombre de un tag, más
    2.49 -allá de lo necesario para asegurar que un tag puede parsearse sin
    2.50 -ambigüedades. El nombre de un tag no puede tener ninguno de los
    2.51 -caracteres siguientes:
    2.52 +Una etiqueta no es más que un ``nombre simbólico'' para una revisión.  Las
    2.53 +etiquetas existen únicamente para su conveniencia, brindándole una forma
    2.54 +permanente y sencilla de referirse a una revisión; Mercurial no
    2.55 +interpreta de ninguna manera los nombres de las etiquetas que usted use.
    2.56 +Mercurial tampoco impone restricción alguna al nombre de una etiqueta, más
    2.57 +allá de lo necesario para asegurar que una etiqueta pueda procesarse sin
    2.58 +ambigüedades. El nombre de una etiqueta no puede tener ninguno de los
    2.59 +siguientes caracteres:
    2.60  \begin{itemize}
    2.61  \item Dos puntos (ASCII 58, ``\texttt{:}'')
    2.62 -\item Retroceso (return) (ASCII 13, ``\Verb+\r+'')
    2.63 +\item Retorno de carro (return) (ASCII 13, ``\Verb+\r+'')
    2.64  \item Nueva línea (ASCII 10, ``\Verb+\n+'')
    2.65  \end{itemize}
    2.66  
    2.67 -Puede usar la orden \hgcmd{tags} para observar los tags presentes en
    2.68 +Puede usar la orden \hgcmd{tags} para observar las etiquetas presentes en
    2.69  su repositorio. Al desplegarse, cada revisión marcada se identifica
    2.70  primero con su nombre, después el número de revisión y finalmente con
    2.71  un hash único de la revisión.
    2.72 @@ -55,7 +57,7 @@
    2.73  \texttt{tip} es un tag ``flotante'' especial, que identifica siempre
    2.74  la revisión más nueva en el repositorio.
    2.75  
    2.76 -Al desplegar la orden \hgcmd{tags}, los tags se listan en orden
    2.77 +Al desplegar la orden \hgcmd{tags}, las etiquetas se listan en orden
    2.78  inverso, por número de revisión. Lo que significa usualmente que los
    2.79  tags más recientes se listan antes que los más antiguos. También
    2.80  significa que el tag \texttt{tip} siempre aparecerá como primer tag
    2.81 @@ -84,7 +86,7 @@
    2.82  que asegura que cada revisión puede generarse limpiamente, estaría
    2.83  introduciendo mucho ruido si se usara un tag para cada generación
    2.84  exitosa. Más bien, podría usar tags para generaciones fallidas (en
    2.85 -caso de que estas sean raras!), o simplemente evitar los tags para
    2.86 +caso de que estas sean raras!), o simplemente evitar las etiquetas para
    2.87  llevar cuenta de la posibilidad de generación de binarios.
    2.88  
    2.89  
    2.90 @@ -102,15 +104,15 @@
    2.91  mover el tag hacia la revisión correcta tan pronto como localice el
    2.92  error.
    2.93  
    2.94 -Mercurial almacena los tags en un archivo controlado por revisiones en
    2.95 -su repositorio. Si ha creado tags, los encontrará en un archivo
    2.96 +Mercurial almacena las etiquetas en un archivo controlado por revisiones en
    2.97 +su repositorio. Si ha creado etiquetas, las encontrará en un archivo
    2.98  llamado \sfilename{.hgtags}.  Cuando invoca la orden \hgcmd{tag},
    2.99 -Mercurial modifica este archivo, y automáticamente hace commit del
   2.100 +Mercurial modifica este archivo, y automáticamente hace 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  \interaction{tag.tip}
   2.104  
   2.105 -\subsection{Manejo de conflictos entre tags durante una fusión}
   2.106 +\subsection{Manejo de conflictos entre etiquetas durante una fusión}
   2.107  
   2.108  Es usual no tener que preocuparse por el archivo \sfilename{.hgtags},
   2.109  pero aveces hace su aparición durante una fusión. El formato del
   2.110 @@ -121,7 +123,7 @@
   2.111  Si está resolviendo un conflicto en el archivo \sfilename{.hgtags}
   2.112  durante una fusión, hay un detalle para tener en cuenta al modificar
   2.113  el archivo \sfilename{.hgtags}:
   2.114 -cuando Mercurial parsea los tags en el repositorio \emph{nunca}
   2.115 +cuando Mercurial parsea las etiquetas en el repositorio \emph{nunca}
   2.116  lee la copia de trabajo del archivo \sfilename{.hgtags}.  En cambio,
   2.117  lee la versión \emph{consignada más reciente} del archivo.
   2.118  
   2.119 @@ -154,11 +156,11 @@
   2.120  exactamente el subconjunto correcto de la historia del proyecto en el
   2.121  nuevo repositorio, pero, \emph{no} el tag que podría haber esperado.
   2.122  
   2.123 -\subsection{Cuando los tags permanentes son demasiado}
   2.124 -
   2.125 -Dado que los tags de Mercurial están controlados por revisiones y se
   2.126 +\subsection{Cuando las etiquetas permanentes son demasiado}
   2.127 +
   2.128 +Dado que las etiquetas de Mercurial están controladas por revisiones y se
   2.129  llevan en la historia del proyecto, todas las personas involucradas
   2.130 -verán los tags que usted haya creado. El hecho de dar nombres a las
   2.131 +verán las etiquetas que usted haya creado. El hecho de dar nombres a las
   2.132  revisiones tiene usos más allá que simplemente hacer notar que la
   2.133  revisión \texttt{4237e45506ee} es realmente \texttt{v2.0.2}.  Si está
   2.134  tratando de encontrar un bug sutil, posiblemente desearía colocar un