🚀 go-pugleaf

Hola, Count Zero:

Count Zero wrote:
> Posible Off-Topic dado que por el tipo de questiones que planteo se 
> ajustar�a m�s a instalaci�n o redes, pero ya que se trata de una 
> herramienta fundamental para el programador creo que se ajusta m�s aqu� y 
> obtendr� mejores respuestas.
> 
> He dado una ojeada al Cederquist y al CVS-BestPractice (alguien sabe si hay 
> traducci�n de �ste �ltimo al espa�ol?).
> 
> 1)
> Diferencia entre 'branch' y 'release' ? (Soy novatillo en esto, lo siento)
> 

'Branch' es rama y 'release' versi�n.  F�cil �no?
Con m�s calma: el formato de ficheros del repositorio CVS es RCS.  Este 
formato permite mantener "versiones" del mismo fichero a lo largo del 
tiempo.  Cada una de estas versiones del fichero es una "release" del mismo.
As�, la vez que a�ades un fichero al repositorio, de �ste se dice que 
est� en la versi�n (release) 1.1.  Cuando haces cambios en el fichero es 
ingresas estos cambios en el repositorio, el fichero pasa a la versi�n 
1.2, despu�s 1.3, 1.4, etc. Como ves, se sigue un formato lineal: 
primero la 1.1, luego la 1.2, luego 1.3... RCS (y por lo tanto CVS) 
permite tambi�n establecer para un fichero distintas "ramas evolutivas" 
(branches).  La funcionalidad de las mismas es permitir desarrollo 
paralelo por m�s de una persona/equipo simult�neamente: imagina que 
tienes un programa que, por mor de la sencillez, consta de un s�lo 
fichero.  Este programa accede a un fichero de texto, lo lee, hace 
ciertos c�lculos y presenta un resultado al usuario.  Despu�s de un 
tiempo de desarrollo, digamos que el fichero est� en su revisi�n 1.25 y 
que pr�cticamente es estable (s�lo se corrigen errores).  En ese 
momento, alguien decide que ser�a buena cosa que el programa pudiese 
acceder tambi�n a un base de datos y no s�lo a un fichero.  En un 
entorno sin "ramas", har�as una nueva copia del fichero, que guardar�as 
a parte, por si aparecen nuevos bugs en la versi�n estable del programa 
y comenzar�as nuevo desarrollo, largo y con m�ltiples revisiones 
intermedias antes de poder finalmente a�adir la nueva funcionalidad. 
Los cambios en la versi�n estable que hubiesen ocurrido entre tanto 
tendr�an que ser estudiados para saber si se correspond�an a bugs que 
pudiesen afectar tambi�n a la nueva versi�n y ser�an a�adidos despu�s a 
esta.  En un entorno CVS esto mismo se consigue a�adiendo "ramas" 
(branches) al desarrollo.  En nuestro supuesto, crear�as una rama (y una 
etiqueta para poder encontrar m�s tarde este punto) a la altura de la 
revisi�n 1.25 (que a fecha de hoy, coindice con la cabeza -HEAD- de 
desarrollo) con algo como `cvs -b v_1_0` para la correcci�n de los bugs. 
  Esto crear�a la rama 1.25.1, la primera revisi�n de la cual para 
nuestro fichero ser�a la 1.25.1.1.  Ahora el desarrollo hacia la nueva 
versi�n del programa lo seguir�as haciendo en la rama principal (TRUNK) 
en tanto que las correcciones de la versi�n estable las llevar�as a cabo 
en la rama 1.25.1, a la que has dado el nombre simb�lico "v_1_0".  M�s 
adelante podr�a incluso integrar los cambios de la rama estable (digamos 
que has corregido tres bugs en ella y que la �ltima revisi�n de ese 
fichero en esa rama fuese la 1.25.1.17) haciendo uso de la opci�n -j 
(aunque no recuerdo ahora mismo la sintaxis exacta).

> 2)
> Hay alguna forma de usar cvspserver de forma segura ?  (encriptada o algo 
> as�). Por ahora uso SSH, pero los logs de sistema no distinguen las 
> conexiones SSH normales de las del CVS.
> 

En dos palabras: N-O
Sigue con CVS que ya vas bien.

> 3)
> Supongamos que un modulo del repositorio esta formado enteramente de 
> archivos binarios, hay alguna forma de indicarle esto al CVS sin tener 
> tocar el ./~cvsignore o tener que usar el cvs -kb ?
> 

No, directamente.  Pero si tienes suerte y estos ficheros tiene 
extensiones constantes y previsibles, puedes a�adirlas al fichero 
CVSROOT/cvswrappers.  Por ejemplo, sabes que los fichero *.gif son 
binarios: puedes a�adir la siguiente l�nea al fichero cvswrappers:

*.[Gg][Ii][Ff] -m COPY -k 'b'


> 4)
> Es posible usar m�s de un servidor ?
> 
> Ejemplo: Tengo el servidor CVS principal, hago un cvs update des de un 
> port�til y luego en el port�til desconectado de la red uso el mismo host 
> como servidor CVS hasta que vuelva a conectarme con el CVS original.
> 

S� y no.  La respuesta "oficial" es que no, ya que el repositorio de 
conexi�n queda establecido en el fichero CVS/Root de tu sandbox.  No 
obstante, si lo cambias a mano (y hay por ah� alg�n script ya hecho) no 
hay problema (desde el punto de vista de la conexi�n).

De todos modos, en tu caso necesitar�s esto *y* el uso de alguna 
herramienta como cvsup para migrar los cambio.  La operativa ser�a m�s o 
menos la siguiente.
1/ Trabajas con conexi�n: tienes una sanbox "contra" el servidor principal.
2/ Preparas la desconexi�n: para ello utilizar cvsup para sincronizar el 
repositorio en tu portatil con el princiapl.
3/ Desconectas.  Ahora puedes optar por tener una sandbox *distinta* de 
la anterior para conectar al repositorio del portatil (si en tu sandbox 
del servidor principal no hab�a cambios pendientes, no habr� diferencia) 
o utilizas un script para cambiar el nombre del repositorio en tu 
sandbox al actual.
4/ Reconectas: vuelves a utilizar cvsup, en esta ocasi�n en direcci�n 
contraria para pasar los cambios en tu repositorio del portatil al 
repositorio principal y...
5/ Utilizas la misma estrategia que en 3 para volver a trabajar "contra" 
el repositorio principal.

En todo caso, y si las desconexiones son por tiempo limitado, quiz� 
podr�as pasar sin actualizar los cambios a ning�n repositorio el tiempo 
que est�s desconectado, en cuyo caso el repositorio del port�til no 
ser�a necesario.

> 5)
> Supongamos que quiero hacer un repositorio de los directorios /etc/cron.* 
> (hourly, daily, weekly y monthly) dado que hay m�s archivos a parte de 
> estos en el /etc, hay alguna forma transparente de hacerlo?
> 

No.  Ni tampoco te interesa.  Sin entrar en mucho detalle, por la forma 
en que trabaja CVS te conviene tener una sandbox propia, editar all� los 
ficheros conforme sea menester, hacer ci y co en ella, y cuando est�s 
satisfecho con un cambio, s�lo entonces, devuelves la nueva versi�n a su 
lugar.  Yo tengo un repositorio, uno de cuyos m�dulos se llama equipos, 
a su vez con "subm�dulos" nombrados seg�n el FQDN de cada m�quina que 
administro.  Al subm�dulo de una m�quina voy a�adiendo los ficheros que 
edito, la primera vez que lo hago.  Luego, en mi directorio particular, 
tendo un subdirectorio en el que tengo sanboxes de los m�dulos 
correspondientes a las m�quinas con las que est� trabajando en el 
momento.  Si hay que cambiar, digamos, el cron horario de la m�quina 
www.example.com, entonces edito el fichero en la sandbox 
equipos/www_example_com/etc/cron.hourly/tarea.sh, y cuando he acabado, 
lo copio (con scp, normalmente) a su m�quina de destino.  Compruebo que 
funciona el cambio y cuando estoy conforme, hago el check-in del fichero 
editado con un comentario apropiado.

> 6) y �tlimo
> Algunas recomendaciones bibliogr�ficas a parte del Cederquist, 
> CVS-BestPractices, RCS-CVS Howto y el Micro-como de Olea ?
> 

Pues que te suscribas al grupo de noticias gnu.cvs.help.
-- 
SALUD,
Jes�s
***
jesus_navarro@undominio.net
***