10 de Enero, 2005

Trabajando con RCS (y 2)

Ayer ya comenté algunos usos de RCS, pero por no liarla demasiado me dejé algunas cosas, como poner ejemplos prácticos.

Sí, ya sé que puse ejemplos, pero no ejemplos prácticos.

Está claro que con lo que expliqué ayer sobre anotar versiones, por empezar por alguna parte, implica que seamos condenadamente buenos programando. ¿Cómo saber que ese check in que estamos haciendo va a ser la versión x.y de nuestro software?

Lo más normal es que la caguemos varias veces y vayamos rectificando hasta que estemos satisfechos como para publicar una versión. Tampoco hay que hacer revisiones a lo loco, pero sí podemos relajarnos un poco y así cuando el código está bien probado, ponemos la anotación. Sí, se puede hacer a posteriori, gracias a rcs (el comando).

Supongamos que he llegado llegado a un buen punto para la versión 1.2.1 de mi bogom. Concretamente se trata de una corrección sobre la versión anterior (me equivoqué y la opción -c no funcionaba :P).

Bueno, hago un check in y como veo que no hay más cosas que corregir, marco la nueva versión:

$ rcs -nBOGOM_1_2_1: milter.c

Así he asignado la marca BOGOM_1_2_1 a la versión 1.9 (la actual de trabajo, se denota con los dos puntos) del fichero milter.c. Podríamos indicarle tras los dos puntos la versión concreta a marcar, o borrar la marca si no indicamos ni los dos puntos.

Esto es comodísimo, porque si alguien me informa de un error en la versión 1.2.1, probablemente yo haya seguido desarrollando y mis fuentes pueden no ser un punto fiable para programar la corrección. Ahora solo tendré que emplear co con -rBOGOM_1_2_1 para tener a mano el fuente en su estado concreto. Crearía una nueva rama para la corrección y sacaría versión (1.2.2), para sincronizar con la rama de desarrollo más adelante (para la futura 1.3).

Incluso se podría emplear el número de revisión directamente, pero por experiencia sé que el usuario bastante tiene con indicar qué versión del programa se bajó de la web :).

Otra utilidad de rcs es que nos permite hacer rectificaciones. Supongamos que hacemos un check in y posteriormente nos damos cuenta que hemos hecho mal la modificación, o que simplemente nos hemos dejado algo sin cambiar. En ese caso podemos eliminar la revisión:

$ rcs -o1.9

Hay algunos requisitos, como que no hayan bloqueos (locks, lo que hacemos con el -l que nos permite seguir trabajando en la siguiente versión) ni sub-ramas de desarrollo. Pero vamos, es útil poder rectificar al menos los últimos cambios (ojo que puede ser útil hacer copia del fichero antes de borrar la revisión).

También es útil indicar cual es nuestra rama de desarrollo por defecto. Cuando hacemos un ci siempre se asume que estamos trabajando con una rama de desarrollo, a no ser que explícitamente indiquemos la versión. Podemos indicar, por ejemplo, que nuestra nueva rama de desarrollo por defecto es la 1.9.1.1 (suponiendo que ha habido un error en la versión 1.2.1 que hablábamos hace un momento):

$ rcs -b1.9.1.1 milter.c

De esta forma todo los check in por defecto irán a esa rama. Se puede volver a la rama normal (la de número de versión más alto) con -b sin indicar revisión.

Y con esto creo que ya he terminado de liar al que no estaba ya suficientemente liado :D. Esta es mi forma de trabajar, distinguiendo entre versiones publicadas y revisiones (o versiones, puede que haya alternado entre estas dos palabras sin darme cuenta) de los fuentes. Desde luego pueden haber otros mecanismos, aunque el funcionamiento de las herramientas siempre será el mismo.

Anotación por Juan J. Martínez.

Los comentarios están cerrados: los comentarios se cierran automáticamente una vez pasados 30 días. Si quieres comentar algo acerca de la anotación, puedes hacerlo por e-mail.