🚀 go-pugleaf

Hola, Conde:

Count Zero wrote:
> Iba "Jes�s M. NAVARRO" por es.comp.os.linux.programacion
> 
> Primero de todo, muchas gracias por la velocidad, la calidad y la cantidad 
> de respuestas. (pensaba recibir varias respuestas separadas no un 'todo en 
> una') ;).
> 
> 
>>'Branch' es rama y 'release' versi�n.  F�cil �no?
> 
> 
> Si te he comprendido bien seria como....
> 
> Debian: branch -> Woody o Sarge, release -> 2.2, 3.0, etc...
> Kernel: branch -> 2.4 o 2.5, release -> 2.4.18, 2.4.19, ...
> 

Pues s�, m�s o menos.  Para ser exactos, "branching" es el proceso 
operativo que en CVS da soporte al concepto l�gico de ramas de 
desarrollo (digo esto porque, por ejemplo, en el caso de kernel, si se 
controlase el c�digo con CVS se har�a, en general, como indicas: , 2.0, 
2.2 y 2.4 ser�an distintas ramas -la 2.5, por ser la �ltima, en 
desarrollo actualmente, estar�a probablemente en el "tronco" del 
desarrollo, mientras que 2.4.19 ser�a una release... tampoco de manera 
exacta porque, obviamente, el kernel de linux contiene m�s de un fichero 
;^D  En realidad, 2.4.19 ser�a un tag simb�lico que abarcar�a ficheros 
en m�ltiples revisiones distintas.  Por otra parte, es archiconocido qu 
e a Linus Torvalds no le gusta CVS y, por lo tanto, no lo usa).

> Si �s asi, como tu comentas en tu ejemplo en el que en una 'rama' se 
> establece una nueva funcionalidad al margen de los bugs de la anterior 
> 'rama' mientras se solucionan estos.
> 

S�: �ste ser�a *un* uso adecuado para la opci�n de branching que soporta 
CVS.

> Una vez resueltos los bugs de la rama original, y suponiendo que la nueva 
> rama con la nueva funcionalidad ya est� terminada, c�mo se 'unen' para 
> tener una versi�n la la nueva funcionalidad (nueva rama) con los bugs de la 
> rama original solucionados ?
> 

�Pues c�mo va a ser?  �Pues ley�ndose el manual, por supuesto!  El 
Cederqvist es expl�cito en eso y a �l me remito: en mi versi�n 
(v1.11.2-debian) el cap�tulo 5 se titula, precisamente, "Branching and 
merging".

> (Espero explicar-me bien, esto parece un paja mental)
> 
> 
>>En dos palabras: N-O
>>Sigue con CVS que ya vas bien.
> 
> 
> Recibio, cambio y corto.
> 

Quer�a decir "sigue con ssh", supongo que me habr�s entendido pese al 
'lapsus calami'.  En realidad, el uso de pserver puede ser v�lido en el 
caso de acceso an�nimo s�lo lectura, pero nada m�s.

>>>4)
>>>Es posible usar m�s de un servidor ?
>>>
>>
>>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.
> 
> 
> Mejora har� esto, veo que es complicarse mucho la vida. Gracias
> 
> 
> 
>>>5)
>>
>>
> 
> Ok, para el caso que necesito creo que me manejar� bien con un par de 
> scripts.
> 

Otra opci�n m�s simple, si s�lo se trata de un equipo y te conviene 
editar el fichero en su propio lugar, podr�a ser utilizar directamente 
RCS en lugar de CVS en esos ficheros.
-- 
SALUD,
Jes�s
***
jesus_navarro@undominio.net
***