42-47 diseño.qxd
20/12/06
15:18
Página 55
DISEÑO
Sistemas SCM para la Gestión de la Configuración del Software (I) por el mismo ítem, el cual permanecerá inmutable a lo largo del tiempo.
Revisión o versión El contenido de un ítem va cambiando a lo largo del tiempo. Para almacenar cada uno de estos estados se emplean las revisiones. Una revisión contendrá el contenido del ítem en un momento dado. En cualquier momento se puede recuperar cualquiera de estas versiones, permitiendo ver el ítem tal y como estaba en el instante en el que la versión fue creada. Una revisión puede tener dos estados: protegida o desprotegida. Cuando se crea mantiene un estado de desprotegida (checkout). Mientras está en este estado puede ser modificada por parte del usuario. Cuando el usuario confirma los cambios en el ítem, éste pasa a guardarse en el sistema, pasando la revisión al estado de protegida (checkin). Una vez que una revisión está en este estado no puede alterarse. Para modificarla será necesario desprotegerla creando una nueva revisión con el estado de desprotegida. Algunos sistemas son capaces de almacenar también las revisiones mientras están desprotegidas, conservando estos datos en el repositorio y no sólo localmente.
Figura 1. Evolución de un ítem en una rama.
Figura 2. Evolución de un ítem en varias ramas simultáneamente.
http://digital.revistasprofesionales.com
Rama Es uno de los conceptos más complejos dentro de un SCM, pero también es uno de los que les confiere una mayor potencia. Una rama es una línea temporal en la cual han ido evolucionando uno o más ítems. Esta línea temporal normalmente se denomina “línea de trabajo”. Un ítem va cambiando a lo largo del tiempo. Cada vez que lo modificamos partimos de un contenido inicial, que es la revisión que estamos viendo (revisión padre). Para crear una nueva revisión con el contenido modificado. Estos cambios que se van haciendo a lo largo del tiempo crean una línea temporal, en la que cada revisión viene seguida por una y precedida por otra. Todas estas revisiones, que representan cómo ha ido evolucionando un elemento a lo largo del tiempo, se encuentran contenidas dentro de una rama, tal y como puede verse en la figura 1. Si un ítem va a ser modificado de más de una manera simultáneamente (e independientemente), el elemento pasará de tener una línea temporal, a tener tantas como de formas distintas vaya a ser modificado. Para poder hacer esto se crearán tantas ramas como evoluciones vaya a tener el ítem, manteniendo en cada rama una línea temporal de los cambios del ítem, como se muestra en la figura 2. Al crear distintas ramas, el ítem puede ir evolucionando de formas diferentes, sin que la forma en la que se cambia su contenido en una rama afecte a las demás. Aunque la información contenida en una rama es independiente a la que está contenida en las demás, en ocasiones queremos propagar los cambios sufridos por uno o más ítems en una rama hacia otra. Para propagar los cambios entre las ramas se emplean los rebases y las integraciones, que se realizan a través de la operación de merge. Dada la complejidad de estas acciones se explicarán detenidamente en un próximo artículo. Una rama almacenará un conjunto de revisiones para uno o más ítems. Todas las revisiones de un mismo ítem dentro de la rama, tienen una relación lineal. Cada revisión mantiene un estado del ítem, que da lugar al siguiente estado del ítem después de que un usuario lo modifique y así sucesivamente. De ahí que la
rama contenga una línea temporal en la que ha evolucionado uno o más ítems. Es importante aclarar que toda revisión se encuentra necesariamente en una rama, y sólo en una.
Etiqueta Una etiqueta permite marcar una revisión concreta de uno o más ítems para poder referirnos a ella con mayor facilidad en cualquier momento. A todos los efectos, lo que hace es asociar un nombre con el que referirse a esa revisión concreta de cada ítem. Pero una etiqueta no puede ser aplicada a más de una revisión de un mismo ítem, de manera que permite recuperar fácilmente un estado para todos los ítems marcados por ella. El caso habitual es etiquetar todos los ítems del espacio de trabajo. De esta manera la etiqueta nos permitiría recuperar una configuración concreta de todo sistema. Normalmente, en entornos de desarrollo, se aplica una etiqueta a todo el sistema siempre que se realiza una release (una nueva versión del sistema que se está desarrollando).
Link Un link permite relacionar dos objetos del repositorio. Los links pueden ser creados por el usuario y en algunos casos por el propio sistema. Un usuario creará un link de cierto tipo (creando un tipo de relación), que luego usará para relacionar un par de objetos contenidos en el repositorio. Hay que entender que un link puede estar creado sin que ningún par de objetos estén relacionados por el mismo. Pero obligatoriamente para relacionar un par de objetos, es necesario haber creado un link que represente ese tipo de relación. Por ejemplo, podría crearse un link “implementa requisito”, mediante el cual se relacionarán las especificaciones de requisitos, con los ficheros de código que las implementan, para luego aplicar ese link a cada documento de requisitos con todos ficheros de código necesarios para implementarle. De los links creados por el sistema, el más importante es el de merge. Un link de merge relaciona dos revisiones del sistema. Indicando que una es el resultado de mezclar el contenido de su revisión padre, con el contenido de la del 55
SOLO PROGRAMADORES nº 145