CVS: Modelo complejo (loginfo)
Hace algún tiempo que he probado las primeras delicias del CVS. Desde entonces han surgido nuevos requisitos para intentar mejorar el uso del versionado. Entre tales situaciones un entorno particular me ha hecho creer más aún en CVS como gestor de versiones.
La situación -fictícea o no- podría ser la siguiente: supongamos un desarrollo compartido con varias máquinas clientes y dos servidores. Los clientes se encargan de programar el producto final y probarlo en el primer servidor al que llamaremos devel. Una vez el producto ha pasado la fase de pruebas y depuración de errores se podría pasar al servidor definitivo que etiquetaremos como producción.
Resumiendo tenemos a varios desarrolladores programando en sus ordenadores, probando el producto en un entorno común (devel) y que al final se subirá a un servidor en producción. Para más inri el producto final se trata de una aplicación web, con lo que tiene que estar accesible y navegable en devel para comprobar su correcto funcionamiento.
El rompecabezas viene al intentar automatizar todo lo posible el versionado del producto. La solución pasaba por tener un repositorio central en devel (/home/cvs por ejemplo) donde irían los distintos módulos. A su vez y para poder probar el producto, deberíamos tener también una copia del último checkout en /var/www/pruebas. Con lo que, los desarrolladores deberían hacer un commit de los cambios y un checkout en el servidor devel. ¡Un coñazo!... ¿o no?.
Aquí empiezan las buenas noticias -¡menos mal!-, CVS tiene un archivo que procesa triggers cada vez que se hace un commit, este archivo es el CVSROOT/loginfo y se utiliza normalmente para redirigir o parsear logs de lo que pasa en el repositorio cuando alguien confirma nuevos cambios.
Vamos a servirnos de su amabilidad para lo que nos interesa, con una sola linea de código automatizaremos ese checkout que nos trae de cabeza, agregamos en CVSROOT/loginfo lo siguiente:
Decir que esta linea es básica y muy mejorable, con un poco de ingenio podremos hacer que, a la vez que genera el checkout nos mande un correo con los cambios en cada commit ;). Lo próximo será montar un cvsweb para poder acceder al código directamente vía web.
Agradecimientos a MarcosBL por las pruebas y el tiempo gastado intentando que todo fuera bien, a Betabug y Wildweasel por soportar mi pésimo inglés y por abrirme la mente hacia este tip definitivo.
La situación -fictícea o no- podría ser la siguiente: supongamos un desarrollo compartido con varias máquinas clientes y dos servidores. Los clientes se encargan de programar el producto final y probarlo en el primer servidor al que llamaremos devel. Una vez el producto ha pasado la fase de pruebas y depuración de errores se podría pasar al servidor definitivo que etiquetaremos como producción.
Resumiendo tenemos a varios desarrolladores programando en sus ordenadores, probando el producto en un entorno común (devel) y que al final se subirá a un servidor en producción. Para más inri el producto final se trata de una aplicación web, con lo que tiene que estar accesible y navegable en devel para comprobar su correcto funcionamiento.
El rompecabezas viene al intentar automatizar todo lo posible el versionado del producto. La solución pasaba por tener un repositorio central en devel (/home/cvs por ejemplo) donde irían los distintos módulos. A su vez y para poder probar el producto, deberíamos tener también una copia del último checkout en /var/www/pruebas. Con lo que, los desarrolladores deberían hacer un commit de los cambios y un checkout en el servidor devel. ¡Un coñazo!... ¿o no?.
Aquí empiezan las buenas noticias -¡menos mal!-, CVS tiene un archivo que procesa triggers cada vez que se hace un commit, este archivo es el CVSROOT/loginfo y se utiliza normalmente para redirigir o parsear logs de lo que pasa en el repositorio cuando alguien confirma nuevos cambios.
Vamos a servirnos de su amabilidad para lo que nos interesa, con una sola linea de código automatizaremos ese checkout que nos trae de cabeza, agregamos en CVSROOT/loginfo lo siguiente:
DEFAULT cd /var/www/pruebas/ && /usr/bin/cvs -qd /home/cvs/repositorio/ up -PACd moduloY cada vez que se haga un commit automáticamente el sistema generará un checkout de la última versión en el directorio accesible por web (si en la anterior linea cambiamos modulo por * regenerará todos los módulos del repositorio). Ojo, el primer checkout debe hacerse manualmente para que este sistema funcione (si no encuentra código en /var/www/pruebas/ dará error).
Decir que esta linea es básica y muy mejorable, con un poco de ingenio podremos hacer que, a la vez que genera el checkout nos mande un correo con los cambios en cada commit ;). Lo próximo será montar un cvsweb para poder acceder al código directamente vía web.
Agradecimientos a MarcosBL por las pruebas y el tiempo gastado intentando que todo fuera bien, a Betabug y Wildweasel por soportar mi pésimo inglés y por abrirme la mente hacia este tip definitivo.
Comentarios