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