jerojasro@515: %% vim: tw=70 encoding=utf8 jerojasro@515: \chapter{Administración de versiones y desarrollo ramificado} igor@324: \label{chap:branch} igor@324: jerojasro@531: Mercurial ofrece varios mecanismos que le permiten administrar un igor@324: proyecto que avanza en múltiples frentes simultáneamente. Para igor@324: entender estos mecanismos, demos un vistazo a la estructura usual de igor@324: un proyecto de software. igor@324: jerojasro@515: Muchos proyectos de software liberan una versión ``mayor'' que contiene igor@324: nuevas características substanciales. En paralelo, pueden liberar jerojasro@515: versiones ``menores''. Usualmente éstas son idénticas a las jerojasro@515: versiones mayores en las cuales están basadas, pero con arreglos para igor@324: algunos fallos. igor@324: igor@324: En este capítulo, comenzaremos hablando de cómo mantener registro de jerojasro@532: etapas del proyecto como las liberaciones de una igor@324: versión. Continuaremos hablando del flujo de trabajo entre las jerojasro@532: diferentes fases de un proyecto, y cómo puede ayudar Mercurial a jerojasro@532: aislar y administrar tal trabajo. igor@324: igor@324: \section{Dar un nombre persistente a una revisión} igor@324: jerojasro@532: Cuando usted decide otorgar a una revisión el nombre particular de una jerojasro@515: ``versión'', es buena idea grabar la identidad de tal revisión. jerojasro@515: Esto le permitirá reproducir dicha versión en una fecha posterior, jerojasro@515: para cualquiera que sea el jerojasro@515: propósito que se tenga en ese momento (reproducir un fallo, portar igor@324: a una nueva plataforma, etc). igor@324: \interaction{tag.init} igor@324: igor@324: Mercurial le permite dar un nombre permanente a cualquier revisión igor@324: usando la orden \hgcmd{tag}. Sin causa de sorpresa, esos nombres se llaman jerojasro@515: ``tags'' (etiquetas). igor@324: \interaction{tag.tag} igor@324: jerojasro@515: Una etiqueta no es más que un ``nombre simbólico'' para una revisión. Las jerojasro@515: etiquetas existen únicamente para su conveniencia, brindándole una forma jerojasro@515: permanente y sencilla de referirse a una revisión; Mercurial no jerojasro@515: interpreta de ninguna manera los nombres de las etiquetas que usted use. jerojasro@515: Mercurial tampoco impone restricción alguna al nombre de una etiqueta, más jerojasro@515: allá de lo necesario para asegurar que una etiqueta pueda procesarse sin jerojasro@515: ambigüedades. El nombre de una etiqueta no puede tener ninguno de los jerojasro@515: siguientes caracteres: igor@324: \begin{itemize} igor@324: \item Dos puntos (ASCII 58, ``\texttt{:}'') jerojasro@515: \item Retorno de carro (return) (ASCII 13, ``\Verb+\r+'') igor@324: \item Nueva línea (ASCII 10, ``\Verb+\n+'') igor@324: \end{itemize} igor@324: jerojasro@532: Puede usar la orden \hgcmd{tags} para ver las etiquetas presentes en igor@324: su repositorio. Al desplegarse, cada revisión marcada se identifica jerojasro@532: primero con su nombre, después con el número de revisión y finalmente con igor@324: un hash único de la revisión. igor@324: \interaction{tag.tags} jerojasro@532: Note que \texttt{tip} aparece en en listado generado por \hgcmd{tags}. La etiqueta jerojasro@519: \texttt{tip} es una etiqueta ``flotante'' especial, que identifica siempre jerojasro@532: la revisión más reciente en el repositorio. igor@324: jerojasro@515: Al desplegar la orden \hgcmd{tags}, las etiquetas se listan en orden jerojasro@532: inverso, por número de revisión. Lo que significa usualmente que las jerojasro@532: etiquetas más recientes se listan antes que las más antiguas. También jerojasro@519: significa que la etiqueta \texttt{tip} siempre aparecerá como primera jerojasro@519: etiqueta listada al desplegar la orden \hgcmd{tags}. jerojasro@519: jerojasro@532: Cuando usted ejecuta \hgcmd{log}, si se muestra una revisión que tenga jerojasro@532: etiquetas asociadas a ella, se imprimirán tales etiquetas. igor@324: \interaction{tag.log} igor@324: jerojasro@531: Siempre que requiera indicar un~ID de revisión a una orden de jerojasro@519: Mercurial, aceptará un nombre de etiqueta en su lugar. Internamente, jerojasro@531: Mercurial traducirá su nombre de etiqueta en el~ID de revisión igor@324: correspondiente, y lo usará. igor@324: \interaction{tag.log.v1.0} igor@324: jerojasro@531: No hay límites en la cantidad de etiquetas por repositorio, o la cantidad jerojasro@519: de etiquetas que una misma revisión pueda tener. Siendo prácticos, no es jerojasro@532: muy buena idea tener ``demasiadas'' (la cantidad variará de un igor@330: proyecto a otro), debido a que la intención es ayudarle a encontrar jerojasro@532: revisiones. Si tiene demasiadas etiquetas, la facilidad de usarlas jerojasro@532: para identificar revisiones disminuirá rápidamente. jerojasro@532: jerojasro@532: Por ejemplo, si su proyecto tiene etapas (milestones) frecuentes, de pocos jerojasro@519: días, es perfectamente razonable asignarle una etiqueta a cada una de igor@330: ellas. Pero si tiene un sistema de construcción automática de binarios igor@330: que asegura que cada revisión puede generarse limpiamente, estaría jerojasro@519: introduciendo mucho ruido si se usara una etiqueta para cada generación jerojasro@533: exitosa. Más bien, podría usar tags para generaciones fallidas jerojasro@533: (\textexclamdown en jerojasro@515: caso de que estas sean raras!), o simplemente evitar las etiquetas para igor@330: llevar cuenta de la posibilidad de generación de binarios. igor@330: igor@324: jerojasro@532: Si quiere eliminar una etiqueta que no desea, use igor@324: \hgcmdargs{tag}{--remove}. igor@324: \interaction{tag.remove} jerojasro@532: También puede modificar una etiqueta en cualquier momento, para que jerojasro@532: identifique una revisión distinta, simplemente usando una nueva orden igor@331: \hgcmd{tag}. Deberá usar la opción \hgopt{tag}{-f} para indicarle a jerojasro@532: Mercurial que \emph{realmente} desea actualizar la etiqueta. igor@324: \interaction{tag.replace} igor@331: De todas maneras habrá un registro permanente de la antigua identidad jerojasro@532: de la etiqueta, pero Mercurial no la usará. Por lo tanto no hay jerojasro@532: problema al marcar con una etiqueta una revisión incorrecta; lo único jerojasro@532: que debe hacer es mover la etiqueta hacia la revisión correcta tan jerojasro@532: pronto como localice el error. igor@331: jerojasro@516: Mercurial almacena las etiquetas en un fichero controlado por revisiones en jerojasro@516: su repositorio. Si ha creado etiquetas, las encontrará en un fichero igor@331: llamado \sfilename{.hgtags}. Cuando invoca la orden \hgcmd{tag}, jerojasro@533: Mercurial modifica este fichero, y hace la consignación del cambio al jerojasro@533: mismo automáticamente. Esto significa que cada vez que ejecuta jerojasro@533: \hgcmd{tag}, verá un conjunto de cambios correspondiente en la salida jerojasro@533: de \hgcmd{log}. igor@324: \interaction{tag.tip} igor@324: jerojasro@515: \subsection{Manejo de conflictos entre etiquetas durante una fusión} igor@331: jerojasro@532: Usualmente no tendrá que preocuparse por el fichero \sfilename{.hgtags}, jerojasro@532: pero a veces hace su aparición durante una fusión. El formato del jerojasro@516: fichero es sencillo: Consiste de una serie de líneas. Cada línea jerojasro@532: comienza con un hash de conjunto de cambios, seguido por un espacio, jerojasro@519: seguido por el nombre de una etiqueta. igor@331: jerojasro@516: Si está resolviendo un conflicto en el fichero \sfilename{.hgtags} igor@331: durante una fusión, hay un detalle para tener en cuenta al modificar jerojasro@516: el fichero \sfilename{.hgtags}: jerojasro@533: cuando Mercurial procesa las etiquetas en el repositorio, \emph{nunca} jerojasro@516: lee la copia de trabajo del fichero \sfilename{.hgtags}. En cambio, jerojasro@516: lee la versión \emph{consignada más reciente} del fichero. igor@331: igor@331: Una consecuencia desafortunada de este diseño es que usted no puede jerojasro@532: verificar que su fichero \sfilename{.hgtags} fusionado sea correcto hasta jerojasro@531: \emph{después} de haber consignado un cambio. Así que si se igor@331: encuentra resolviendo un conflicto en \sfilename{.hgtags} durante una igor@331: fusión, asegúrese de ejecutar la orden \hgcmd{tags} después de jerojasro@516: consignar. Si encuentra un error en el fichero \sfilename{.hgtags}, jerojasro@532: la orden reportará el lugar del error, que podrá arreglar y después igor@331: consignar. Posteriormente ejecute de nuevo la orden \hgcmd{tags} para jerojasro@532: asegurarse de que su arreglo fue aplicado correctamente . jerojasro@532: jerojasro@532: \subsection{Etiquetas y clonado} igor@331: igor@331: Puede haber notado que la orden \hgcmd{clone} tiene la opción igor@331: \hgopt{clone}{-r} que le permite clonar una copia exacta del igor@331: repositorio hasta un conjunto de cambios específico. El nuevo clon no jerojasro@516: tendrá historial posterior a la revisión que usted haya jerojasro@532: especificado. Esto tiene una interacción con etiquetas que puede jerojasro@532: sorprender a los desprevenidos. igor@331: jerojasro@519: Recuerde que una etiqueta se almacena como una revisión al fichero jerojasro@532: \sfilename{.hgtags}, así que cuando usted crea una etiqueta, el jerojasro@532: conjunto de cambios en el cual ésta se almacena necesariamente se igor@331: refiere a un conjunto de cambios anterior. Cuando ejecuta jerojasro@519: \hgcmdargs{clone}{-r foo} para clonar un repositorio hasta la etiqueta jerojasro@516: \texttt{foo}, el nuevo clon \emph{no contendrá el historial que creo jerojasro@519: la etiqueta} que usó para clonar el repositorio. El resultado es que tendrá jerojasro@517: exactamente el subconjunto correcto del historial del proyecto en el jerojasro@519: nuevo repositorio, pero, \emph{no} la etiqueta que podría haber esperado. igor@331: jerojasro@515: \subsection{Cuando las etiquetas permanentes son demasiado} jerojasro@515: jerojasro@515: Dado que las etiquetas de Mercurial están controladas por revisiones y se jerojasro@516: llevan en el historial del proyecto, todas las personas involucradas jerojasro@515: verán las etiquetas que usted haya creado. El hecho de dar nombres a las igor@331: revisiones tiene usos más allá que simplemente hacer notar que la igor@331: revisión \texttt{4237e45506ee} es realmente \texttt{v2.0.2}. Si está jerojasro@531: tratando de encontrar un fallo sutil, posiblemente desearía colocar una jerojasro@533: etiqueta recordándole algo como ``Ana vio los síntomas en esta revisión''. igor@331: jerojasro@532: Para estos casos, lo que posiblemente desearía serían etiquetas jerojasro@519: \emph{locales}. Puede crear una etiqueta local con la opción \hgopt{tag}{-l} jerojasro@519: de la orden \hgcmd{tag}. Esto guardará la etiqueta en un fichero llamado igor@331: \sfilename{.hg/localtags}. A diferencia de \sfilename{.hgtags}, igor@331: \sfilename{.hg/localtags} no está controlado por revisiones. jerojasro@532: Cualquier etiqueta que usted cree usando \hgopt{tag}{-l} se mantendrá jerojasro@532: localmente al repositorio en el que esté trabajando en ese momento. igor@331: igor@331: \section{El flujo de cambios---El gran cuadro vs. el pequeño} igor@331: igor@331: Retomando lo mencionado en el comienzo de un capítulo, pensemos en el igor@331: hecho de que un proyecto tiene muchas piezas concurrentes de trabajo igor@331: en desarrollo al mismo tiempo. igor@331: jerojasro@532: Puede haber prisa por una nueva versión ``principal''; una nueva jerojasro@531: versión con un arreglo de fallo a la última versión; y una versión de igor@331: ``mantenimiento correctivo'' a una versión antigua que ha entrado en igor@331: modo de mantenimiento. igor@331: igor@331: Usualmente la gente se refiere a esas direcciones jerojasro@532: concurrentes de desarrollo como ``ramas''. Sin embargo, ya hemos visto que jerojasro@532: en varias ocasiones Mercurial trata a \emph{todo el historial} como igor@331: una serie de ramas y fusiones. Realmente lo que tenemos aquí es dos igor@331: ideas que se relacionan periféricamente, pero que en esencia comparten igor@331: un nombre. igor@324: \begin{itemize} igor@331: \item ``El gran cuadro'' Las ramas representan un barrido de la igor@331: evolución del proyecto; la gente les da nombres y hablan acerca de igor@331: ellas en sus conversaciones. igor@331: \item ``El cuadro pequeño'' Las ramas son artefactos de las jerojasro@532: actividades diarias de desarrollar y fusionar cambios. Exponen la igor@331: narrativa de cómo se desarrolló el código. igor@324: \end{itemize} igor@324: igor@337: \section{Administrar ramas en repositorios estilo gran cuadro} igor@337: igor@337: En Mercurial la forma más sencilla de aislar una rama del ``gran igor@337: cuadro'' es a través de un repositorio dedicado. Si cuenta con un igor@337: repositorio compartido existente ---llamémoslo igor@337: \texttt{myproject}---que alcanzó la etapa ``1.0'', puede comenzar a igor@337: prepararse para versiones de mantenimiento futuras a partir de la jerojasro@532: versión~1.0 marcando con una etiqueta la revisión con la cual preparó la versión~1.0. igor@324: \interaction{branch-repo.tag} igor@337: Ahora puede clonar un repositorio compartido nuevo jerojasro@532: \texttt{myproject-1.0.1} con tal etiqueta. igor@324: \interaction{branch-repo.clone} igor@324: igor@337: Posteriormente, si alguien necesita trabajar en la reparación de un igor@337: fallo debería dirigirse a la liberación de versión~1.0.1 que viene en igor@337: camino, ellos clonarían el repositorio \texttt{myproject-1.0.1}, jerojasro@532: harían sus cambios y los empujarían de vuelta. igor@324: \interaction{branch-repo.bugfix} igor@337: Mientras tanto, el desarrollo para la siguiente versión mayor puede jerojasro@532: continuar aislado e incólume, en el repositorio \texttt{myproject}. igor@324: \interaction{branch-repo.new} igor@324: igor@342: \section{No repita trabajo: fusión entre ramas} igor@342: igor@342: En muchos casos, cuando tiene un fallo para arreglar en una rama de igor@342: mantenimiento, es muy probable que el fallo esté también en la rama jerojasro@521: principal (y posiblemente en otras ramas de mantenimiento igor@342: también). Solamente un desarrollador extraño desearía corregir el igor@342: mismo fallo muchas veces, por tanto, veremos varias alternativas con igor@342: las que Mercurial puede ayudarle a administrar tales arreglos de fallo igor@342: sin duplicar su trabajo. igor@342: igor@342: En el caso más sencillo, basta con jalar los cambios de la rama de jerojasro@531: mantenimiento a la rama objetivo en su clon local. igor@324: \interaction{branch-repo.pull} jerojasro@532: A continuación deberá mezclar las cabezas de las dos ramas, y empujar igor@342: de nuevo a la rama principal. igor@324: \interaction{branch-repo.merge} igor@324: igor@342: \section{Nombrar ramas dentro de un repositorio} igor@342: igor@342: La aproximación correcta en casi todas las oportunidades es aislar las igor@342: ramas en los repositorios. Es fácil de entender gracias a su jerojasro@532: simplicidad; y es difícil cometer errores. Hay una relación uno a uno igor@342: entre las ramas y los directorios con los que está trabajando en su jerojasro@532: sistema. Esto le permite usar emplear herramientas usuales (que no son jerojasro@532: conscientes de Mercurial) para trabajar con los ficheros dentro de una igor@342: rama/repositorio. igor@342: igor@342: Si se encuentra más en la categoría ``usuario diestro'' (\emph{y} sus igor@342: colaboradores también), puede considerar otra alternativa para jerojasro@531: administrar las ramas. He mencionado con anterioridad la distinción a igor@342: nivel humano entre las ramas estilo ``cuadro pequeño'' y ``gran igor@342: cuadro''. Mientras que Mercurial trabaja con muchas ramas del estilo jerojasro@520: ``cuadro pequeño'' en el repositorio todo el tiempo (por ejemplo cuando igor@342: usted jala cambios, pero antes de fusionarlos), \emph{también} puede igor@342: trabajar con varias ramas del ``cuadro grande''. igor@342: igor@342: El truco para trabajar de esta forma en Mercurial se logra gracias a igor@342: que puede asignar un \emph{nombre} persistente a una rama. Siempre igor@342: existe una rama llamada \texttt{default}. Incluso antes de que igor@342: empiece a nombrar ramas por su cuenta, puede encontrar indicios de la igor@342: rama \texttt{default} si los busca. igor@342: igor@342: Por ejemplo, cuando invoca la orden \hgcmd{commit}, y se lanza su igor@342: editor para introducir el mensaje de la consignación, busque la línea igor@342: que contiene el texto ``\texttt{HG: branch default}'' al final. Le igor@342: está indicando que su consignación ocurrirá en la rama llamada igor@324: \texttt{default}. igor@324: jerojasro@532: Use la orden \hgcmd{branches} para empezar a trabajar con ramas igor@342: nombradas. Esta orden mostrará las ramas presentes en su repositorio, jerojasro@532: indicándole qué conjunto de cambios es la punta de cada una. igor@324: \interaction{branch-named.branches} jerojasro@532: Dado que todavía no ha creado ramas nombradas, la única que verá será igor@342: \texttt{default}. igor@342: igor@342: Para hallar cuál es la rama ``actual'', invoque la orden igor@342: \hgcmd{branch}, sin argumento alguno. Le informará en qué rama se jerojasro@532: encuentra el padre del conjunto de cambios actual. igor@324: \interaction{branch-named.branch} igor@324: igor@342: Para crear una nueva rama, invoque la orden \hgcmd{branch} de igor@342: nuevo. En esta oportunidad, ofrezca un argumento: el nombre de la rama igor@342: que desea crear. igor@324: \interaction{branch-named.create} igor@324: igor@342: Después de crear la rama, usted podría desear ver el efecto que tuvo igor@342: la orden \hgcmd{branch}. ¿Qué reportan las ordenes \hgcmd{status} y jerojasro@532: \hgcmd{tip}? igor@324: \interaction{branch-named.status} jerojasro@516: Nada cambia en el directorio actual, y no se ha añadido nada al jerojasro@516: historial. Esto sugiere que al ejecutar la orden \hgcmd{branch} no hay igor@342: un efecto permanente; solamente le indica a que nombre de rama usará igor@342: la \emph{próxima} vez que consigne un conjunto de cambios. igor@342: jerojasro@531: Cuando consigna un cambio, Mercurial almacena el nombre de la rama en igor@342: la cual consignó. Una vez que haya cambiado de la rama \texttt{default} igor@342: y haya consignado, verá que el nombre de la nueva rama se mostrará igor@342: cuando use la orden \hgcmd{log}, \hgcmd{tip}, y otras órdenes que igor@342: desplieguen la misma clase de información. igor@324: \interaction{branch-named.commit} igor@342: Las órdenes del tipo \hgcmd{log} imprimirán el nombre de la rama de jerojasro@532: cualquier conjunto de cambios que no esté en la rama igor@342: \texttt{default}. Como resultado, si nunca usa ramas nombradas, nunca igor@342: verá esta información. igor@342: igor@342: Una vez que haya nombrado una rama y consignado un cambio con ese igor@342: nombre, todas las consignaciones subsecuentes que desciendan de ese igor@342: cambio heredarán el mismo nombre de rama. Puede cambiar el nombre de igor@342: una rama en cualquier momento con la orden \hgcmd{branch}. igor@324: \interaction{branch-named.rebranch} igor@342: Esto es algo que no hará muy seguido en la práctica, debido que los igor@342: nombres de las ramas tienden a tener vidas largas. (Esto no es una igor@342: regla, solamente una observación.) igor@342: igor@342: \section{Tratamiento de varias ramas nombradas en un repositorio} igor@342: igor@342: Si tiene más de una rama nombrada en un repositorio, Mercurial igor@342: recordará la rama en la cual está su directorio de trabajo cuando igor@342: invoque una orden como \hgcmd{update} o \hgcmdargs{pull}{-u}. Se jerojasro@532: actualizará su directorio de trabajo actual a la punta de esta rama, sin jerojasro@532: importar cuál sea la punta ``a lo largo del repositorio''. Para jerojasro@531: actualizar a una revisión que está en una rama con distinto nombre, igor@342: puede necesitar la opción \hgopt{update}{-C} de \hgcmd{update}. igor@342: jerojasro@532: Este comportamiento puede ser sutil, así que veámoslo en acción. Primero, igor@342: recordemos en qué rama estamos trabajando, y qué ramas están en igor@342: nuestro repositorio. igor@324: \interaction{branch-named.parents} igor@342: Estamos en la rama \texttt{bar}, pero existe otra rama más antigua igor@342: llamada \hgcmd{foo}. igor@342: igor@342: Podemos hacer \hgcmd{update} entre los tipos de las ramas \texttt{foo} igor@342: y \texttt{bar} sin necesidad de usar la opción \hgopt{update}{-C}, igor@342: puesto que esto solamente implica ir linealmente hacia adelante y jerojasro@516: atrás en nuestro historial de cambios. igor@324: \interaction{branch-named.update-switchy} igor@324: igor@342: Si volvemos a la rama \texttt{foo} e invocamos la orden \hgcmd{update}, jerojasro@532: nos mantendrá en \texttt{foo}, sin movernos a la punta de \texttt{bar}. igor@342: \interaction{branch-named.update-nothing} igor@342: igor@342: Al consignar un cambio a la rama \texttt{foo} se introducirá una nueva igor@342: cabeza. igor@342: \interaction{branch-named.foo-commit} igor@342: igor@342: \section{Nombres de ramas y fusiones} igor@342: igor@342: Posiblemente ha notado que las fusiones en Mercurial no son simétricas. jerojasro@531: Supongamos que su repositorio tiene dos cabezas, 17 y 23. Si yo invoco igor@342: \hgcmd{update} a 17 y aplico \hgcmd{merge} a 23, Mercurial almacena 17 igor@342: como el primer padre de la fusión, y 23 como el segundo. Mientras que igor@342: si hago \hgcmd{update} a 23 y después aplico \hgcmd{merge} con 17, igor@342: grabará a 23 como el primer padre, y 17 como el segundo. igor@342: jerojasro@533: Esto afecta el cómo elige Mercurial el nombre de la rama cuando usted jerojasro@533: hace la fusión. Después de una fusión, Mercurial mantendrá el nombre de la jerojasro@533: rama del primer padre cuando consigne el resultado de la fusión. Si igor@342: el primer nombre de su padre es \texttt{foo}, y fusiona con igor@342: \texttt{bar}, el nombre de la rama continuará siendo \texttt{foo} igor@342: después de fusionar. igor@342: igor@342: No es inusual que un repositorio contenga varias cabezas, cada una con igor@342: el mismo nombre de rama. Digamos que estoy trabajando en la rama jerojasro@533: \texttt{foo}, y usted también. Consignamos cambios distintos; yo jalo igor@342: sus cambios; Ahora tengo dos cabezas, cada una afirmando estar en la igor@342: rama \texttt{foo}. El resultado de una fusión será una única cabeza igor@342: en la rama \texttt{foo} como usted esperaría. igor@342: igor@342: Pero si estoy trabajando en la rama \texttt{bar}, y fusiono el trabajo jerojasro@533: de la rama \texttt{foo}, el resultado permanecerá en la rama igor@324: \texttt{bar}. igor@324: \interaction{branch-named.merge} igor@324: jerojasro@531: En un ejemplo más concreto, si yo estoy trabajando en la rama igor@342: \texttt{bleeding-edge}, y deseo traer los arreglos más recientes de la igor@342: rama \texttt{estable}, Mercurial elegirá el nombre de rama ``correcto'' igor@342: (\texttt{bleeding-edge}) cuando yo jale una fusión desde \texttt{estable}. igor@342: igor@342: \section{Normalmente es útil nombrar ramas} igor@342: igor@342: No debería considerar que las ramas nombradas son aplicables jerojasro@533: únicamente en situaciones con muchas ramas de larga vida cohabitando igor@342: en un mismo repositorio. Son muy útiles incluso en los casos de jerojasro@533: una rama por repositorio. igor@342: igor@342: En el caso más sencillo, dar un nombre a cada rama ofrece un registro igor@342: permanente acerca de en qué conjunto de cambios se generó la rama. jerojasro@516: Esto le ofrece más contexto cuando esté tratando de seguir el jerojasro@516: historial de un proyecto ramificado de larga vida. igor@342: igor@342: Si está trabajando con repositorios compartidos, puede configurar el gancho igor@342: \hook{pretxnchangegroup} para que cada uno bloquee los cambios con igor@342: nombres de rama ``incorrectos'' que están por adicionarse. Este jerojasro@533: provee una defensa sencilla, pero efectiva, para evitar que la gente jerojasro@533: publique accidentalmente cambios de una rama ``super nueva'' a la rama igor@342: ``estable''. Tal gancho podría verse de la siguiente forma dentro de igor@342: un repositorio compartido de \hgrc. igor@324: \begin{codesample2} igor@324: [hooks] igor@324: pretxnchangegroup.branch = hg heads --template '{branches} ' | grep mybranch igor@324: \end{codesample2} igor@324: igor@324: %%% Local Variables: igor@324: %%% mode: latex igor@324: %%% TeX-master: "00book" igor@324: %%% End: