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