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