hgbook

annotate es/branch.tex @ 516:9da096de3c52

find changesets by author, revision, files, or words in the commit message
changed "historia" to "historial".
changed "archivo" to "fichero"
corrected some typos
author Javier Rojas <jerojasro@devnull.li>
date Sun Jan 18 21:37:11 2009 -0500 (2009-01-18)
parents aa01d35ac59f
children 3f32047a3f25
rev   line source
jerojasro@515 1 %% vim: tw=70 encoding=utf8
jerojasro@515 2 \chapter{Administración de versiones y desarrollo ramificado}
igor@324 3 \label{chap:branch}
igor@324 4
igor@324 5 Mercurial ofrece varios mecanismos que le permitirán administrar un
igor@324 6 proyecto que avanza en múltiples frentes simultáneamente. Para
igor@324 7 entender estos mecanismos, demos un vistazo a la estructura usual de
igor@324 8 un proyecto de software.
igor@324 9
jerojasro@515 10 Muchos proyectos de software liberan una versión ``mayor'' que contiene
igor@324 11 nuevas características substanciales. En paralelo, pueden liberar
jerojasro@515 12 versiones ``menores''. Usualmente éstas son idénticas a las
jerojasro@515 13 versiones mayores en las cuales están basadas, pero con arreglos para
igor@324 14 algunos fallos.
igor@324 15
igor@324 16 En este capítulo, comenzaremos hablando de cómo mantener registro de
igor@324 17 las etapas del proyecto como las liberaciones de una
igor@324 18 versión. Continuaremos hablando del flujo de trabajo entre las
igor@324 19 diferentes fases de un proyecto, y como puede ayudar Mercurial a
igor@324 20 independizar y administrar tal trabajo.
igor@324 21
igor@324 22 \section{Dar un nombre persistente a una revisión}
igor@324 23
igor@324 24 Cuando se decide a otorgar a una revisión el nombre particular de una
jerojasro@515 25 ``versión'', es buena idea grabar la identidad de tal revisión.
jerojasro@515 26 Esto le permitirá reproducir dicha versión en una fecha posterior,
jerojasro@515 27 para cualquiera que sea el
jerojasro@515 28 propósito que se tenga en ese momento (reproducir un fallo, portar
igor@324 29 a una nueva plataforma, etc).
igor@324 30 \interaction{tag.init}
igor@324 31
igor@324 32 Mercurial le permite dar un nombre permanente a cualquier revisión
igor@324 33 usando la orden \hgcmd{tag}. Sin causa de sorpresa, esos nombres se llaman
jerojasro@515 34 ``tags'' (etiquetas).
igor@324 35 \interaction{tag.tag}
igor@324 36
jerojasro@515 37 Una etiqueta no es más que un ``nombre simbólico'' para una revisión. Las
jerojasro@515 38 etiquetas existen únicamente para su conveniencia, brindándole una forma
jerojasro@515 39 permanente y sencilla de referirse a una revisión; Mercurial no
jerojasro@515 40 interpreta de ninguna manera los nombres de las etiquetas que usted use.
jerojasro@515 41 Mercurial tampoco impone restricción alguna al nombre de una etiqueta, más
jerojasro@515 42 allá de lo necesario para asegurar que una etiqueta pueda procesarse sin
jerojasro@515 43 ambigüedades. El nombre de una etiqueta no puede tener ninguno de los
jerojasro@515 44 siguientes caracteres:
igor@324 45 \begin{itemize}
igor@324 46 \item Dos puntos (ASCII 58, ``\texttt{:}'')
jerojasro@515 47 \item Retorno de carro (return) (ASCII 13, ``\Verb+\r+'')
igor@324 48 \item Nueva línea (ASCII 10, ``\Verb+\n+'')
igor@324 49 \end{itemize}
igor@324 50
jerojasro@515 51 Puede usar la orden \hgcmd{tags} para observar las etiquetas presentes en
igor@324 52 su repositorio. Al desplegarse, cada revisión marcada se identifica
igor@324 53 primero con su nombre, después el número de revisión y finalmente con
igor@324 54 un hash único de la revisión.
igor@324 55 \interaction{tag.tags}
igor@324 56 Note que \texttt{tip} aparece en la lista de \hgcmd{tags}. El tag
igor@324 57 \texttt{tip} es un tag ``flotante'' especial, que identifica siempre
igor@324 58 la revisión más nueva en el repositorio.
igor@324 59
jerojasro@515 60 Al desplegar la orden \hgcmd{tags}, las etiquetas se listan en orden
igor@324 61 inverso, por número de revisión. Lo que significa usualmente que los
igor@324 62 tags más recientes se listan antes que los más antiguos. También
igor@324 63 significa que el tag \texttt{tip} siempre aparecerá como primer tag
igor@324 64 listado al desplegar la orden \hgcmd{tags}.
igor@324 65
igor@324 66 Cuando ejecuta \hgcmd{log}, se desplegará la revisión que tenga los
igor@324 67 tags asociados a ella, se imprimirán tales tags.
igor@324 68 \interaction{tag.log}
igor@324 69
igor@324 70 Siempre que requiera indicar un ~ID de revisión a una Orden de
igor@324 71 Mercurial, aceptará un nombre de tag en su lugar. Internamente,
igor@324 72 Mercurial traducirá su nombre de tag en el ~ID de revisión
igor@324 73 correspondiente, y lo usará.
igor@324 74 \interaction{tag.log.v1.0}
igor@324 75
igor@330 76 No hay límites en la cantidad de tags por reposirorio, o la cantidad
igor@330 77 de tags que una misma revisión pueda tener. Siendo prácticos, no es
igor@330 78 muy buena idea tener ``demasiados'' (la cantidad variará de un
igor@330 79 proyecto a otro), debido a que la intención es ayudarle a encontrar
igor@330 80 revisiones. Si tiene demasiados tags, la facilidad para identificar
igor@330 81 revisiones disminuirá rápidamente.
igor@330 82
igor@330 83 Por ejemplo, si su proyecto tiene etapas(milestones) frecuentes en pocos
igor@330 84 días, es perfectamente razonable asignarle un tag a cada una de
igor@330 85 ellas. Pero si tiene un sistema de construcción automática de binarios
igor@330 86 que asegura que cada revisión puede generarse limpiamente, estaría
igor@330 87 introduciendo mucho ruido si se usara un tag para cada generación
igor@330 88 exitosa. Más bien, podría usar tags para generaciones fallidas (en
jerojasro@515 89 caso de que estas sean raras!), o simplemente evitar las etiquetas para
igor@330 90 llevar cuenta de la posibilidad de generación de binarios.
igor@330 91
igor@324 92
igor@331 93 Si desea eliminar un tag que no desea, use
igor@324 94 \hgcmdargs{tag}{--remove}.
igor@324 95 \interaction{tag.remove}
igor@331 96 También puede modificar un tag en cualquier momento para que
igor@331 97 identifique una revisión distinta, basta con aplicar una nueva orden
igor@331 98 \hgcmd{tag}. Deberá usar la opción \hgopt{tag}{-f} para indicarle a
igor@331 99 Mercurial que desea actualizar el tag \emph{en serio}.
igor@324 100 \interaction{tag.replace}
igor@331 101 De todas maneras habrá un registro permanente de la antigua identidad
igor@331 102 del tag, pero Mercurial no la usará. Por lo tanto no hay castigo al
igor@331 103 marcar con un tag una revisión incorrecta; lo único que debe hacer es
igor@331 104 mover el tag hacia la revisión correcta tan pronto como localice el
igor@331 105 error.
igor@331 106
jerojasro@516 107 Mercurial almacena las etiquetas en un fichero controlado por revisiones en
jerojasro@516 108 su repositorio. Si ha creado etiquetas, las encontrará en un fichero
igor@331 109 llamado \sfilename{.hgtags}. Cuando invoca la orden \hgcmd{tag},
jerojasro@516 110 Mercurial modifica este fichero, y automáticamente hace consignación del
igor@331 111 cambio al mismo. Esto significa que cada vez que ejecuta \hgcmd{tag},
igor@331 112 verá el conjunto de cambios correspondiente en la salida de \hgcmd{log}.
igor@324 113 \interaction{tag.tip}
igor@324 114
jerojasro@515 115 \subsection{Manejo de conflictos entre etiquetas durante una fusión}
igor@331 116
jerojasro@516 117 Es usual no tener que preocuparse por el fichero \sfilename{.hgtags},
igor@331 118 pero aveces hace su aparición durante una fusión. El formato del
jerojasro@516 119 fichero es sencillo: Consiste de una serie de líneas. Cada línea
igor@331 120 comienza con un hash de Conjunto de Cambios, seguido por un espacio,
igor@331 121 seguido por el nombre de un tag.
igor@331 122
jerojasro@516 123 Si está resolviendo un conflicto en el fichero \sfilename{.hgtags}
igor@331 124 durante una fusión, hay un detalle para tener en cuenta al modificar
jerojasro@516 125 el fichero \sfilename{.hgtags}:
jerojasro@515 126 cuando Mercurial parsea las etiquetas en el repositorio \emph{nunca}
jerojasro@516 127 lee la copia de trabajo del fichero \sfilename{.hgtags}. En cambio,
jerojasro@516 128 lee la versión \emph{consignada más reciente} del fichero.
igor@331 129
igor@331 130 Una consecuencia desafortunada de este diseño es que usted no puede
jerojasro@516 131 verificar que su fichero \sfilename{.hgtags} fusionado es correcto hasta
igor@331 132 \emph{después} de haber consignado(hecho commit). Así que si se
igor@331 133 encuentra resolviendo un conflicto en \sfilename{.hgtags} durante una
igor@331 134 fusión, asegúrese de ejecutar la orden \hgcmd{tags} después de
jerojasro@516 135 consignar. Si encuentra un error en el fichero \sfilename{.hgtags},
igor@331 136 reportará el lugar del error, que podrá arreglar y después
igor@331 137 consignar. Posteriormente ejecute de nuevo la orden \hgcmd{tags} para
igor@331 138 asegurar que su arreglo fue correctamente aplicado.
igor@331 139
igor@331 140 \subsection{Tags y clonado}
igor@331 141
igor@331 142 Puede haber notado que la orden \hgcmd{clone} tiene la opción
igor@331 143 \hgopt{clone}{-r} que le permite clonar una copia exacta del
igor@331 144 repositorio hasta un conjunto de cambios específico. El nuevo clon no
jerojasro@516 145 tendrá historial posterior a la revisión que usted haya
igor@331 146 especificado. Esta forma de interactuar puede sorprender a los
igor@331 147 desprevenidos.
igor@331 148
jerojasro@516 149 Recuerde que un tag se almacena como una revisión al fichero
igor@331 150 \sfilename{.hgtags}, consecuente con esto, cuando crea un tag, el
igor@331 151 conjunto de cambios en el cual este se almacena necesariamente se
igor@331 152 refiere a un conjunto de cambios anterior. Cuando ejecuta
igor@331 153 \hgcmdargs{clone}{-r foo} para clonar un repositorio hasta el tag
jerojasro@516 154 \texttt{foo}, el nuevo clon \emph{no contendrá el historial que creo
igor@331 155 el tag} que usó para clonar el repositorio. El resultado es que tendrá
jerojasro@516 156 exactamente el subconjunto correcto de el historial del proyecto en el
igor@331 157 nuevo repositorio, pero, \emph{no} el tag que podría haber esperado.
igor@331 158
jerojasro@515 159 \subsection{Cuando las etiquetas permanentes son demasiado}
jerojasro@515 160
jerojasro@515 161 Dado que las etiquetas de Mercurial están controladas por revisiones y se
jerojasro@516 162 llevan en el historial del proyecto, todas las personas involucradas
jerojasro@515 163 verán las etiquetas que usted haya creado. El hecho de dar nombres a las
igor@331 164 revisiones tiene usos más allá que simplemente hacer notar que la
igor@331 165 revisión \texttt{4237e45506ee} es realmente \texttt{v2.0.2}. Si está
igor@331 166 tratando de encontrar un bug sutil, posiblemente desearía colocar un
igor@331 167 tag recordándole algo como ``Ana vió los síntomas con esta revisión''.
igor@331 168
igor@331 169 Para estos casos, lo que posiblemente desearía serían tags
igor@331 170 \emph{locales}. Puede crear un tag local con la opción \hgopt{tag}{-l}
jerojasro@516 171 de la orden \hgcmd{tag}. Esto guardará el tag en un fichero llamado
igor@331 172 \sfilename{.hg/localtags}. A diferencia de \sfilename{.hgtags},
igor@331 173 \sfilename{.hg/localtags} no está controlado por revisiones.
igor@331 174 Cualquier tag que usted cree usando \hgopt{tag}{-l} se mantendrá
igor@331 175 localmente en el repositorio en el que esté trabajando en ese momento.
igor@331 176
igor@331 177 \section{El flujo de cambios---El gran cuadro vs. el pequeño}
igor@331 178
igor@331 179 Retomando lo mencionado en el comienzo de un capítulo, pensemos en el
igor@331 180 hecho de que un proyecto tiene muchas piezas concurrentes de trabajo
igor@331 181 en desarrollo al mismo tiempo.
igor@331 182
igor@331 183 Puede haber prisa por una nueva versión ``principal''; Un nueva
igor@331 184 versión con un rreglo de fallo a la última versión; y una versión de
igor@331 185 ``mantenimiento correctivo'' a una versión antigua que ha entrado en
igor@331 186 modo de mantenimiento.
igor@331 187
igor@331 188 Usualmente la gente se refiere a esas direcciones
igor@331 189 concurrentes de desarrollo es como ``ramas''. Aunque hemos visto que
jerojasro@516 190 en variadas ocasiones Mercurial trata a \emph{toda el historial} como
igor@331 191 una serie de ramas y fusiones. Realmente lo que tenemos aquí es dos
igor@331 192 ideas que se relacionan periféricamente, pero que en esencia comparten
igor@331 193 un nombre.
igor@324 194 \begin{itemize}
igor@331 195 \item ``El gran cuadro'' Las ramas representan un barrido de la
igor@331 196 evolución del proyecto; la gente les da nombres y hablan acerca de
igor@331 197 ellas en sus conversaciones.
igor@331 198 \item ``El cuadro pequeño'' Las ramas son artefactos de las
igor@331 199 actividades diarias de al desarrollar y fusionar cambios. Exponen la
igor@331 200 narrativa de cómo se desarrolló el código.
igor@324 201 \end{itemize}
igor@324 202
igor@337 203 \section{Administrar ramas en repositorios estilo gran cuadro}
igor@337 204
igor@337 205 En Mercurial la forma más sencilla de aislar una rama del ``gran
igor@337 206 cuadro'' es a través de un repositorio dedicado. Si cuenta con un
igor@337 207 repositorio compartido existente ---llamémoslo
igor@337 208 \texttt{myproject}---que alcanzó la etapa ``1.0'', puede comenzar a
igor@337 209 prepararse para versiones de mantenimiento futuras a partir de la
igor@337 210 versión~1.0 marcando con un tag en la revisión con la cual preparó la versión~1.0.
igor@324 211 \interaction{branch-repo.tag}
igor@337 212 Ahora puede clonar un repositorio compartido nuevo
igor@337 213 \texttt{myproject-1.0.1} con tal tag.
igor@324 214 \interaction{branch-repo.clone}
igor@324 215
igor@337 216 Posteriormente, si alguien necesita trabajar en la reparación de un
igor@337 217 fallo debería dirigirse a la liberación de versión~1.0.1 que viene en
igor@337 218 camino, ellos clonarían el repositorio \texttt{myproject-1.0.1},
igor@337 219 harían sus cambios y los publicarían(con push).
igor@324 220 \interaction{branch-repo.bugfix}
igor@337 221 Mientras tanto, el desarrollo para la siguiente versión mayor puede
igor@337 222 continuar asilada e incólume, en el repositorio \texttt{myproject}.
igor@324 223 \interaction{branch-repo.new}
igor@324 224
igor@342 225 \section{No repita trabajo: fusión entre ramas}
igor@342 226
igor@342 227 En muchos casos, cuando tiene un fallo para arreglar en una rama de
igor@342 228 mantenimiento, es muy probable que el fallo esté también en la rama
igor@342 229 principal( y posiblemente en otras ramas de mantenimiento
igor@342 230 también). Solamente un desarrollador extraño desearía corregir el
igor@342 231 mismo fallo muchas veces, por tanto, veremos varias alternativas con
igor@342 232 las que Mercurial puede ayudarle a administrar tales arreglos de fallo
igor@342 233 sin duplicar su trabajo.
igor@342 234
igor@342 235 En el caso más sencillo, basta con jalar los cambios de la rama de
igor@342 236 mantenimiento a la rama obetivo en su clon local.
igor@324 237 \interaction{branch-repo.pull}
igor@342 238 A continuación deberá mezclar las cabezas de las dos ramas, y publicar
igor@342 239 de nuevo a la rama principal.
igor@324 240 \interaction{branch-repo.merge}
igor@324 241
igor@342 242 \section{Nombrar ramas dentro de un repositorio}
igor@342 243
igor@342 244 La aproximación correcta en casi todas las oportunidades es aislar las
igor@342 245 ramas en los repositorios. Es fácil de entender gracias a su
igor@342 246 facilidad; y es difícil cometer errores. Hay una relación uno a uno
igor@342 247 entre las ramas y los directorios con los que está trabajando en su
igor@342 248 sistema. Esto le permite usar emplear herramientas usuales(para los
jerojasro@516 249 nuevos a Mercurial) para trabajar con los ficheros dentro de su
igor@342 250 rama/repositorio.
igor@342 251
igor@342 252 Si se encuentra más en la categoría ``usuario diestro'' (\emph{y} sus
igor@342 253 colaboradores también), puede considerar otra alternativa para
igor@342 254 administrar las ramas. He mencionador con anterioridad la distinción a
igor@342 255 nivel humano entre las ramas estilo ``cuadro pequeño'' y ``gran
igor@342 256 cuadro''. Mientras que Mercurial trabaja con muchas ramas del estilo
igor@342 257 ``cuadro pequeño'' en el repositorio todo el tiempo(por ejemplo cuando
igor@342 258 usted jala cambios, pero antes de fusionarlos), \emph{también} puede
igor@342 259 trabajar con varias ramas del ``cuadro grande''.
igor@342 260
igor@342 261 El truco para trabajar de esta forma en Mercurial se logra gracias a
igor@342 262 que puede asignar un \emph{nombre} persistente a una rama. Siempre
igor@342 263 existe una rama llamada \texttt{default}. Incluso antes de que
igor@342 264 empiece a nombrar ramas por su cuenta, puede encontrar indicios de la
igor@342 265 rama \texttt{default} si los busca.
igor@342 266
igor@342 267 Por ejemplo, cuando invoca la orden \hgcmd{commit}, y se lanza su
igor@342 268 editor para introducir el mensaje de la consignación, busque la línea
igor@342 269 que contiene el texto ``\texttt{HG: branch default}'' al final. Le
igor@342 270 está indicando que su consignación ocurrirá en la rama llamada
igor@324 271 \texttt{default}.
igor@324 272
igor@342 273 Use la orden \hgcmd{branches} para comenzar a trabajar con ramas
igor@342 274 nombradas. Esta orden mostrará las ramas presentes en su repositorio,
igor@342 275 indicándole en qué conjunto de cambios está cada una.
igor@324 276 \interaction{branch-named.branches}
igor@342 277 Dado que todavía no ha creado ramas nombradas, la única que verá sería
igor@342 278 \texttt{default}.
igor@342 279
igor@342 280 Para hallar cuál es la rama ``actual'', invoque la orden
igor@342 281 \hgcmd{branch}, sin argumento alguno. Le informará en qué rama se
igor@342 282 encuentra el padre del conjunto actual de cambios.
igor@324 283 \interaction{branch-named.branch}
igor@324 284
igor@342 285 Para crear una nueva rama, invoque la orden \hgcmd{branch} de
igor@342 286 nuevo. En esta oportunidad, ofrezca un argumento: el nombre de la rama
igor@342 287 que desea crear.
igor@324 288 \interaction{branch-named.create}
igor@324 289
igor@342 290 Después de crear la rama, usted podría desear ver el efecto que tuvo
igor@342 291 la orden \hgcmd{branch}. ¿Qué reportan las ordenes \hgcmd{status} y
igor@324 292 \hgcmd{tip} commands report?
igor@324 293 \interaction{branch-named.status}
jerojasro@516 294 Nada cambia en el directorio actual, y no se ha añadido nada al
jerojasro@516 295 historial. Esto sugiere que al ejecutar la orden \hgcmd{branch} no hay
igor@342 296 un efecto permanente; solamente le indica a que nombre de rama usará
igor@342 297 la \emph{próxima} vez que consigne un conjunto de cambios.
igor@342 298
igor@342 299 Cuando consigna un cambio, Mercurial alamacena el nombre de la rama en
igor@342 300 la cual consignó. Una vez que haya cambiado de la rama \texttt{default}
igor@342 301 y haya consignado, verá que el nombre de la nueva rama se mostrará
igor@342 302 cuando use la orden \hgcmd{log}, \hgcmd{tip}, y otras órdenes que
igor@342 303 desplieguen la misma clase de información.
igor@324 304 \interaction{branch-named.commit}
igor@342 305 Las órdenes del tipo \hgcmd{log} imprimirán el nombre de la rama de
igor@342 306 cualquier conjunto de cambios que no estén en la rama
igor@342 307 \texttt{default}. Como resultado, si nunca usa ramas nombradas, nunca
igor@342 308 verá esta información.
igor@342 309
igor@342 310 Una vez que haya nombrado una rama y consignado un cambio con ese
igor@342 311 nombre, todas las consignaciones subsecuentes que desciendan de ese
igor@342 312 cambio heredarán el mismo nombre de rama. Puede cambiar el nombre de
igor@342 313 una rama en cualquier momento con la orden \hgcmd{branch}.
igor@324 314 \interaction{branch-named.rebranch}
igor@342 315 Esto es algo que no hará muy seguido en la práctica, debido que los
igor@342 316 nombres de las ramas tienden a tener vidas largas. (Esto no es una
igor@342 317 regla, solamente una observación.)
igor@342 318
igor@342 319 \section{Tratamiento de varias ramas nombradas en un repositorio}
igor@342 320
igor@342 321 Si tiene más de una rama nombrada en un repositorio, Mercurial
igor@342 322 recordará la rama en la cual está su directorio de trabajo cuando
igor@342 323 invoque una orden como \hgcmd{update} o \hgcmdargs{pull}{-u}. Se
igor@342 324 actualizará su directorio de trabajo actual al tip de esta rama, sin
igor@342 325 importar cuál sea el tip ``a lo largo del repositorio'' . Para
igor@342 326 actualiar a una revisión que está en una rama con distinto nombre,
igor@342 327 puede necesitar la opción \hgopt{update}{-C} de \hgcmd{update}.
igor@342 328
igor@342 329 Este comportamiento puede ser sutil, veámoslo en acción. Primero,
igor@342 330 recordemos en qué rama estamos trabajando, y qué ramas están en
igor@342 331 nuestro repositorio.
igor@324 332 \interaction{branch-named.parents}
igor@342 333 Estamos en la rama \texttt{bar}, pero existe otra rama más antigua
igor@342 334 llamada \hgcmd{foo}.
igor@342 335
igor@342 336 Podemos hacer \hgcmd{update} entre los tipos de las ramas \texttt{foo}
igor@342 337 y \texttt{bar} sin necesidad de usar la opción \hgopt{update}{-C},
igor@342 338 puesto que esto solamente implica ir linealmente hacia adelante y
jerojasro@516 339 atrás en nuestro historial de cambios.
igor@324 340 \interaction{branch-named.update-switchy}
igor@324 341
igor@342 342 Si volvemos a la rama \texttt{foo} e invocamos la orden \hgcmd{update},
igor@342 343 nos mantendrá en \texttt{foo}, sin movernos al tipo de \texttt{bar}.
igor@342 344 \interaction{branch-named.update-nothing}
igor@342 345
igor@342 346 Al consignar un cambio a la rama \texttt{foo} se introducirá una nueva
igor@342 347 cabeza.
igor@342 348 \interaction{branch-named.foo-commit}
igor@342 349
igor@342 350 \section{Nombres de ramas y fusiones}
igor@342 351
igor@342 352 Posiblemente ha notado que las fusiones en Mercurial no son simétricas.
igor@342 353 Supongamos que su repositorio tiene dos cabezas, 17 and 23. Si yo invoco
igor@342 354 \hgcmd{update} a 17 y aplico \hgcmd{merge} a 23, Mercurial almacena 17
igor@342 355 como el primer padre de la fusión, y 23 como el segundo. Mientras que
igor@342 356 si hago \hgcmd{update} a 23 y después aplico \hgcmd{merge} con 17,
igor@342 357 grabará a 23 como el primer padre, y 17 como el segundo.
igor@342 358
igor@342 359 Esto afecta com elige Mercurial el nombre de la rama cuando hace
igor@342 360 fusión. Después de una fusión Mercurial mantendrá el nombre de la
igor@342 361 rama del primer padre cuando consigne el resultado de una fusión. Si
igor@342 362 el primer nombre de su padre es \texttt{foo}, y fusiona con
igor@342 363 \texttt{bar}, el nombre de la rama continuará siendo \texttt{foo}
igor@342 364 después de fusionar.
igor@342 365
igor@342 366 No es inusual que un repositorio contenga varias cabezas, cada una con
igor@342 367 el mismo nombre de rama. Digamos que estoy trabajando en la rama
igor@342 368 \texttt{foo}, y usted también. Consignamos cambios distintos; Yo jalo
igor@342 369 sus cambios; Ahora tengo dos cabezas, cada una afirmando estar en la
igor@342 370 rama \texttt{foo}. El resultado de una fusión será una única cabeza
igor@342 371 en la rama \texttt{foo} como usted esperaría.
igor@342 372
igor@342 373 Pero si estoy trabajando en la rama \texttt{bar}, y fusiono el trabajo
igor@342 374 desde la rama \texttt{foo}, el resultado permanecerá en la rama
igor@324 375 \texttt{bar}.
igor@324 376 \interaction{branch-named.merge}
igor@324 377
igor@342 378 En un ejemplo más concreo, si yo estoy trabajando en la rama
igor@342 379 \texttt{bleeding-edge}, y deseo traer los arreglos más recientes de la
igor@342 380 rama \texttt{estable}, Mercurial elegirá el nombre de rama ``correcto''
igor@342 381 (\texttt{bleeding-edge}) cuando yo jale una fusión desde \texttt{estable}.
igor@342 382
igor@342 383 \section{Normalmente es útil nombrar ramas}
igor@342 384
igor@342 385 No debería considerar que las ramas nombradas son aplicables
igor@342 386 únicamente en situaciones con muchas ramas de larga-vida cohabitando
igor@342 387 en un mismo repositorio. Son muy útiles incluso en los casos de
igor@342 388 una-rama-por-repositorio.
igor@342 389
igor@342 390 En el caso más sencillo, dar un nombre a cada rama ofrece un registro
igor@342 391 permanente acerca de en qué conjunto de cambios se generó la rama.
jerojasro@516 392 Esto le ofrece más contexto cuando esté tratando de seguir el
jerojasro@516 393 historial de un proyecto ramificado de larga vida.
igor@342 394
igor@342 395 Si está trabajando con repositorios compartidos, puede configurar el gancho
igor@342 396 \hook{pretxnchangegroup} para que cada uno bloquee los cambios con
igor@342 397 nombres de rama ``incorrectos'' que están por adicionarse. Este
igor@342 398 provee una defensa sencilla pero efectiva para evitar que la gente
igor@342 399 accidentalmente publique cambios de una rama ``super nueva'' a la rama
igor@342 400 ``estable''. Tal gancho podría verse de la siguiente forma dentro de
igor@342 401 un repositorio compartido de \hgrc.
igor@324 402 \begin{codesample2}
igor@324 403 [hooks]
igor@324 404 pretxnchangegroup.branch = hg heads --template '{branches} ' | grep mybranch
igor@324 405 \end{codesample2}
igor@324 406
igor@324 407 %%% Local Variables:
igor@324 408 %%% mode: latex
igor@324 409 %%% TeX-master: "00book"
igor@324 410 %%% End: