¿Qué pasa cuándo necesito algo de otra tarea?
Los usuarios de Plastic SCM que han comenzado a usar el patrón de
rama por tarea han visto enseguida la ventaja de poder aislar sus cambios, y sobretodo de poder elegir qué tareas se integran y que tareas quedan fuera en una
release concreta.
Sin embargo, el concepto es mucho más sencillo de asimilar para antiguos usuarios de Clearcase (acostumbrados a los viejos config_specs los selectores les parecen sencillos...) que para ex-sufridores de SourceSafe. Para los segundos su ciclo habitual de trabajo era "necesito tu cambio, haz check-in y lo cojo para seguir ...". Simple, pero muy propenso a propagar errores, por no hablar de la imposibilidad de
elegir qué se
integra y qué no cuando todo está ya en la línea principal.
Se trata, no obstante, de algo totalmente normal. Cuando alguien trabaja sin control de versiones o con uno muy primitivo, está acostumbrado a tener que actualizar continuamente su
copia de trabajo (en el mejor de los casos, cuando no la copia global de todo el equipo) para coger los cambios de los demás. El bloqueo mútuo es constante, y las ventajas de no estar limitado por él evidentes. Pero cambiar los hábitos cuesta trabajo.
Realmente tener que
coger algo de una tarea de otro programador es algo que ocurre excepcionalmente, quizá inversamente proporcional al estado del desarrollo del proyecto (es decir, puede ocurrir más al principio y mucho menos en mantenimiento). La idea es que las tareas sean independientes entre sí siempre que se pueda (hasta que se llega a una release intermedia, que puede ocurrir cada día, una vez a la semana, etc, etc).
El problema es que los programadores que comienzan a usar el nuevo patrón de trabajo tienen una
sensación de urgencia que les lleva a querer incorporar todo lo que hacen sus compañeros a la rama de su tarea actual. Se trata, como decía, de algo totalmente normal. De hecho, mirando alguno de nuestros árboles de versiones, de cuando comenzamos a usar Plastic para gestionar su propio desarrollo y alguno de los miembros del equipo pasaba por una fase similar, se puede apreciar perfectamente el patrón de
merge excesivo entre ramas.
La imagen muestra uno de nuestros ficheros, en una fase muy inicial del desarrollo, y cómo se producen merges sucesivos entre dos ramas (de dos tareas diferentes).
En ocasiones es inevitable (y correcto) que esto ocurra, pero en otras no.
Veamos un ejemplo: la semana pasada estuve trabajando en dos tareas diferentes, por un lado la tarea SCM1457 en la que introduje unas modificaciones en la herramienta gráfica para que funcionase correctamente en Linux, por otro una mejora (SCM1461) que permite fijar el selector para trabajar en una rama o en una etiqueta sin tener que editarlo a mano, sólo con el menú contextual. Más tarde necesitaba grabar un vídeo del sistema funcionando en Linux, y pensé que estaría bien poder mostrar la nueva funcionalidad de cambio de selector. Así que había varias opciones:
- Integrar los cambios de SCM1457 sobre SCM1461 (o viceversa), compilar y grabar el vídeo. Es la opción más sencilla, pero no siempre la más adecuada. ¿Por qué? Supongamos que las correcciones para funcionar en Linux (SCM1457) se integran sobre SCM1461. ¿Qué pasa si posteriormente se descubre que esas correcciones no son correctas en Windows? La tarea 1461 queda afectada por esos cambios, y ya no se puede decidir integrar 1461 y excluir 1457 (como se haría en el escenario habitual), ya que 1461 incluye 1457.
- Crear una nueva rama e integrar ambas sobre ella. Es una opción adecuada, ya que evita los problemas de la aproximación anterior. No obstante en mi caso sólo necesitaba ambas tareas juntas para realizar una simple compilación, sin tener que esperar a la próxima release.
- Usar el selector para coger los contenidos de ambas ramas.
El tercer caso es el que finalmente utilicé, y el que voy a explicar. Observando los contenidos de ambas ramas se veía que no tocaban los mismos ficheros, así que era posible cargar ambos sin necesidad de hacer un merge. De hecho en la tarea para las correcciones en Linux sólo había modificado 2 ficheros, con cargarlos y coger también la rama 1461, sería suficiente.
repository "codice"
// coger el fichero SeidUtils.cs y Optionsform.cs de 1467
path "/01nerva/src/client/security/linuxseid/SeidUtils.cs"
br "/main/FixBL047/SCM1457"
path "/01nerva/src/plastic/OptionsForm.cs"
br "/main/FixBL047/SCM1457"
// el resto de 1461
path "/"
br "/main/FixBL047/SCM1461" lb "BL047.5"
De este modo, sin necesidad de hacer un merge,
se pueden cargar contenidos de más de una ubicación.
Una demostración más de la potencia de los selectores.
0 comentarios:
Publicar un comentario