comparison es/branch.tex @ 614:aa01d35ac59f

replaced several instances of "los tags" with "las etiquetas", corrected typos and so on

613:db12ab3b3b25

\chapter{Administración de Versiones y desarrollo ramificado}
\label{chap:branch}

Mercurial ofrece varios mecanismos que le permitirán administrar un
proyecto que avanza en múltiples frentes simultáneamente. Para
entender estos mecanismos, demos un vistazo a la estructura usual de
un proyecto de software.

Muchos proyectos de software liberan una versión``mayor'' que contiene
nuevas características substanciales.  En paralelo, pueden liberar
versiones ``menores''.   Estas usualmente son idénticas a las
versiones mayores en las cuales están basadas, pero con arreglo de
algunos fallos.

En este capítulo, comenzaremos hablando de cómo mantener registro de
las etapas del proyecto como las liberaciones de una
versión. Continuaremos hablando del flujo de trabajo entre las

independizar y administrar tal trabajo.

\section{Dar un nombre persistente a una revisión}

Cuando se decide a otorgar a una revisión el nombre particular de una
``versión'', es buena idea grabar la identidad para tal revisión.
Lo cual permitirá reproducir tal versión en una fecha posterior, o el
propósito que se considere en ese momento (reproducir un fallo, portar
a una nueva plataforma, etc).
\interaction{tag.init}

Mercurial le permite dar un nombre permanente a cualquier revisión
usando la orden \hgcmd{tag}.  Sin causa de sorpresa, esos nombres se llaman
``tags''(etiquetas).
\interaction{tag.tag}

Un tag no es más que un ``nombre simbólico'' para una revisión.  Los
tags existen únicamente para su conveniencia, dotándolo de una forma
permanente y sencilla para referirse a una revisión; Mercurial no
interpreta de ninguna manera los nombres de los tags que usted use.
Mercurial tampoco impone restricción alguna al nombre de un tag, más
allá de lo necesario para asegurar que un tag puede parsearse sin
ambigüedades. El nombre de un tag no puede tener ninguno de los
caracteres siguientes:
\begin{itemize}
\item Dos puntos (ASCII 58, ``\texttt{:}'')
\item Retroceso (return) (ASCII 13, ``\Verb+\r+'')
\item Nueva línea (ASCII 10, ``\Verb+\n+'')
\end{itemize}

Puede usar la orden \hgcmd{tags} para observar los tags presentes en
su repositorio. Al desplegarse, cada revisión marcada se identifica
primero con su nombre, después el número de revisión y finalmente con
un hash único de la revisión.
\interaction{tag.tags}
Note que \texttt{tip} aparece en la lista de \hgcmd{tags}.  El tag
\texttt{tip} es un tag ``flotante'' especial, que identifica siempre
la revisión más nueva en el repositorio.

Al desplegar la orden \hgcmd{tags}, los tags se listan en orden
inverso, por número de revisión. Lo que significa usualmente que los
tags más recientes se listan antes que los más antiguos. También
significa que el tag \texttt{tip} siempre aparecerá como primer tag
listado al desplegar la orden \hgcmd{tags}.

días, es perfectamente razonable asignarle un tag a cada una de
ellas. Pero si tiene un sistema de construcción automática de binarios
que asegura que cada revisión puede generarse limpiamente, estaría
introduciendo mucho ruido si se usara un tag para cada generación
exitosa. Más bien, podría usar tags para generaciones fallidas (en
caso de que estas sean raras!), o simplemente evitar los tags para
llevar cuenta de la posibilidad de generación de binarios.


Si desea eliminar un tag que no desea, use
\hgcmdargs{tag}{--remove}.  

del tag, pero Mercurial no la usará. Por lo tanto no hay castigo al
marcar con un tag una revisión incorrecta; lo único que debe hacer es
mover el tag hacia la revisión correcta tan pronto como localice el
error.

Mercurial almacena los tags en un archivo controlado por revisiones en
su repositorio. Si ha creado tags, los encontrará en un archivo
llamado \sfilename{.hgtags}.  Cuando invoca la orden \hgcmd{tag},
Mercurial modifica este archivo, y automáticamente hace commit del
cambio al mismo.  Esto significa que cada vez que ejecuta \hgcmd{tag},
verá el conjunto de cambios correspondiente en la salida de \hgcmd{log}.
\interaction{tag.tip}

\subsection{Manejo de conflictos entre tags durante una fusión}

Es usual no tener que preocuparse por el archivo \sfilename{.hgtags},
pero aveces hace su aparición durante una fusión. El formato del
archivo es sencillo: Consiste de una serie de líneas. Cada línea
comienza con un hash de Conjunto de Cambios, seguido por un espacio,
seguido por el nombre de un tag.

Si está resolviendo un conflicto en el archivo \sfilename{.hgtags}
durante una fusión, hay un detalle para tener en cuenta al modificar
el archivo \sfilename{.hgtags}:
cuando Mercurial parsea los tags en el repositorio \emph{nunca}
lee la copia de trabajo del archivo \sfilename{.hgtags}.  En cambio,
lee la versión \emph{consignada más reciente} del archivo.

Una consecuencia desafortunada de este diseño es que usted no puede
verificar que su archivo \sfilename{.hgtags} fusionado es correcto hasta

\texttt{foo}, el nuevo clon \emph{no contendrá la historia que creo
el tag} que usó para clonar el repositorio. El resultado es que tendrá
exactamente el subconjunto correcto de la historia del proyecto en el
nuevo repositorio, pero, \emph{no} el tag que podría haber esperado.

\subsection{Cuando los tags permanentes son demasiado}

Dado que los tags de Mercurial están controlados por revisiones y se
llevan en la historia del proyecto, todas las personas involucradas
verán los tags que usted haya creado. El hecho de dar nombres a las
revisiones tiene usos más allá que simplemente hacer notar que la
revisión \texttt{4237e45506ee} es realmente \texttt{v2.0.2}.  Si está
tratando de encontrar un bug sutil, posiblemente desearía colocar un
tag recordándole algo como ``Ana vió los síntomas con esta revisión''.

614:aa01d35ac59f

%% vim: tw=70 encoding=utf8
\chapter{Administración de versiones y desarrollo ramificado}
\label{chap:branch}

Mercurial ofrece varios mecanismos que le permitirán administrar un
proyecto que avanza en múltiples frentes simultáneamente. Para
entender estos mecanismos, demos un vistazo a la estructura usual de
un proyecto de software.

Muchos proyectos de software liberan una versión ``mayor'' que contiene
nuevas características substanciales.  En paralelo, pueden liberar
versiones ``menores''.   Usualmente éstas son idénticas a las
versiones mayores en las cuales están basadas, pero con arreglos para
algunos fallos.

En este capítulo, comenzaremos hablando de cómo mantener registro de
las etapas del proyecto como las liberaciones de una
versión. Continuaremos hablando del flujo de trabajo entre las

independizar y administrar tal trabajo.

\section{Dar un nombre persistente a una revisión}

Cuando se decide a otorgar a una revisión el nombre particular de una
``versión'', es buena idea grabar la identidad de tal revisión.
Esto le permitirá reproducir dicha versión en una fecha posterior,
para cualquiera que sea el 
propósito que se tenga en ese momento (reproducir un fallo, portar
a una nueva plataforma, etc).
\interaction{tag.init}

Mercurial le permite dar un nombre permanente a cualquier revisión
usando la orden \hgcmd{tag}.  Sin causa de sorpresa, esos nombres se llaman
``tags'' (etiquetas).
\interaction{tag.tag}

Una etiqueta no es más que un ``nombre simbólico'' para una revisión.  Las
etiquetas existen únicamente para su conveniencia, brindándole una forma
permanente y sencilla de referirse a una revisión; Mercurial no
interpreta de ninguna manera los nombres de las etiquetas que usted use.
Mercurial tampoco impone restricción alguna al nombre de una etiqueta, más
allá de lo necesario para asegurar que una etiqueta pueda procesarse sin
ambigüedades. El nombre de una etiqueta no puede tener ninguno de los
siguientes caracteres:
\begin{itemize}
\item Dos puntos (ASCII 58, ``\texttt{:}'')
\item Retorno de carro (return) (ASCII 13, ``\Verb+\r+'')
\item Nueva línea (ASCII 10, ``\Verb+\n+'')
\end{itemize}

Puede usar la orden \hgcmd{tags} para observar las etiquetas presentes en
su repositorio. Al desplegarse, cada revisión marcada se identifica
primero con su nombre, después el número de revisión y finalmente con
un hash único de la revisión.
\interaction{tag.tags}
Note que \texttt{tip} aparece en la lista de \hgcmd{tags}.  El tag
\texttt{tip} es un tag ``flotante'' especial, que identifica siempre
la revisión más nueva en el repositorio.

Al desplegar la orden \hgcmd{tags}, las etiquetas se listan en orden
inverso, por número de revisión. Lo que significa usualmente que los
tags más recientes se listan antes que los más antiguos. También
significa que el tag \texttt{tip} siempre aparecerá como primer tag
listado al desplegar la orden \hgcmd{tags}.

días, es perfectamente razonable asignarle un tag a cada una de
ellas. Pero si tiene un sistema de construcción automática de binarios
que asegura que cada revisión puede generarse limpiamente, estaría
introduciendo mucho ruido si se usara un tag para cada generación
exitosa. Más bien, podría usar tags para generaciones fallidas (en
caso de que estas sean raras!), o simplemente evitar las etiquetas para
llevar cuenta de la posibilidad de generación de binarios.


Si desea eliminar un tag que no desea, use
\hgcmdargs{tag}{--remove}.  

del tag, pero Mercurial no la usará. Por lo tanto no hay castigo al
marcar con un tag una revisión incorrecta; lo único que debe hacer es
mover el tag hacia la revisión correcta tan pronto como localice el
error.

Mercurial almacena las etiquetas en un archivo controlado por revisiones en
su repositorio. Si ha creado etiquetas, las encontrará en un archivo
llamado \sfilename{.hgtags}.  Cuando invoca la orden \hgcmd{tag},
Mercurial modifica este archivo, y automáticamente hace consignación del
cambio al mismo.  Esto significa que cada vez que ejecuta \hgcmd{tag},
verá el conjunto de cambios correspondiente en la salida de \hgcmd{log}.
\interaction{tag.tip}

\subsection{Manejo de conflictos entre etiquetas durante una fusión}

Es usual no tener que preocuparse por el archivo \sfilename{.hgtags},
pero aveces hace su aparición durante una fusión. El formato del
archivo es sencillo: Consiste de una serie de líneas. Cada línea
comienza con un hash de Conjunto de Cambios, seguido por un espacio,
seguido por el nombre de un tag.

Si está resolviendo un conflicto en el archivo \sfilename{.hgtags}
durante una fusión, hay un detalle para tener en cuenta al modificar
el archivo \sfilename{.hgtags}:
cuando Mercurial parsea las etiquetas en el repositorio \emph{nunca}
lee la copia de trabajo del archivo \sfilename{.hgtags}.  En cambio,
lee la versión \emph{consignada más reciente} del archivo.

Una consecuencia desafortunada de este diseño es que usted no puede
verificar que su archivo \sfilename{.hgtags} fusionado es correcto hasta

\texttt{foo}, el nuevo clon \emph{no contendrá la historia que creo
el tag} que usó para clonar el repositorio. El resultado es que tendrá
exactamente el subconjunto correcto de la historia del proyecto en el
nuevo repositorio, pero, \emph{no} el tag que podría haber esperado.

\subsection{Cuando las etiquetas permanentes son demasiado}

Dado que las etiquetas de Mercurial están controladas por revisiones y se
llevan en la historia del proyecto, todas las personas involucradas
verán las etiquetas que usted haya creado. El hecho de dar nombres a las
revisiones tiene usos más allá que simplemente hacer notar que la
revisión \texttt{4237e45506ee} es realmente \texttt{v2.0.2}.  Si está
tratando de encontrar un bug sutil, posiblemente desearía colocar un
tag recordándole algo como ``Ana vió los síntomas con esta revisión''.