🚀 go-pugleaf

Hola, Count:

Count Zero wrote:
> Bueno, gracias a vosotros y un semanita practicando me empiezo a mover 
> agilmente en el mundo del CVS. Gracias a todos.
> 
> Ahora me he hecho un script para 'semi' automatizar la 'instalaci�n' de 
> nuevas versiones. Es decir: coger algo del repositorio y poner lo donde 
> tocar�a, como por ejemplo el repositorio de la p�gina web en el directorio 
> del servidor apache.
> 
> Lo que ara quiero hacer es hacer un script para que me avise via mail 
> cuando haya un nuevo "commit" o un nuevo "tag|rtag". 
> 
> Mirando la documentaci�n ya he visto que debe hacer uso del loginfo, 
> taginfo y tal, pero hay un peque�o problema.
> 
> Si yo meto un script en taginfo y se hace un 'cvs tag' se ejecuta ese 
> script para cada archivo que hay en el repositorio al que se le hace tag, y 
> yo quiero que se ejecute s�lo por cada repositorio afectado (es decir una 
> s�la vez).
> 

El procedimiento est�ndar estriba en el correcto uso de las expresiones 
regulares y un cierto manejo "ad hoc" de CVS.

Como ya has averiguado, dada la naturaleza de CVS, su "unidad de 
trabajo" es el fichero, y todas sus operaciones son "file oriented".

Yo ten�a hechos una serie de scripts para manejar las situaciones en las 
que te hayas ahora pero, desgraciadamente, se han perdido "en la noche 
de los tiempos".  No obstante, todos se basaban en los mismos principios:
1/ Tags con "contenido sem�ntico": antes o despu�s te encontrar�s con 
que cierta operaci�n, basada en tags tendr�a que tener excepciones, y no 
te gustar� tener que ir activando/desactivando tus scripts.  Utiliza las 
expresiones regulares *tambi�n* contra los tags (as�, deber� estar 
documentado que -por ejemplo, lo detalles concretos dependen de tu 
implementaci�n-, los tags en la forma 'v_lo_que_sea', corresponder�n a 
versiones que tienen que ir a producci�n, mientras que 'mn_lo_que_sea', 
son versiones internas de mantenimiento, y que cualquier otro tag ser� 
ignorado por los scripts).
2/ Operar *siempre* contra m�dulos completos: as�, si existe el m�dulo 
"sitio_web_1", todas las operaciones globales las llevar�s a cabo en 
este nivel y no en niveles interiores (`cvs tag sitio_web_1`, no `cvs 
tag sitio_web_1/fichero.txt`).  Esto permite, adem�s, el uso de un 
"fichero sabio" que te permitir� convertir operaciones "file oriented" 
en operaciones "module oriented" simplemente con realizarlas cuando el 
"fichero sabio" se vea afectado.

As�, veamos el caso pr�ctico de uso de taginfo:
El cuarto par�metro que se pasa al script es un "array" que contiene el 
nombre del fichero afectado y la revisi�n: si utilizas un "fichero 
sabio", te basta con que el script s�lo haga lo que tenga que hacer 
cuando el nombre del fichero coincida con el del "fichero sabio", 
teniendo en cuenta que la operaci�n "tag" (trata de evitar rtag en la 
medida de lo posible, salvo cuando puedas asociarla a otro tag ya 
establecido) s�lo la ejecutar�s contra un m�dulo completo.  El esqueleto 
del script que t� invocar�s podr�a ser algo as�:

#!/bin/bash

readonly SMARTFILE="log.txt"

case "$4" in
	SMARTFILE)
		# Hago lo que tenga que hacer
	;;
	*)
		# Esto no me interesa procesarlo
	;;
esac

exit 0


(ojo: en tus primeras pruebas, lim�tate a enviar a la salida est�ndar 
los par�metros de entrada, porque te estoy hablando de memoria y quiz� 
el formato de los par�metros de entrada no sea exactamente el que te digo).
-- 
SALUD,
Jes�s
***
jesus_navarro@undominio.net
***