🚀 go-pugleaf

Hola, Count:

Count Zero wrote:
> Iba "Jes�s M. NAVARRO" por es.comp.os.linux.programacion

[...]

> 
> Me quer�a referir ha si da muchos 'conflictos' cuando deseas 'unir' una 
> rama con la release anterior para solucionar anteriores bugs.�Se maneja 
> bien o puede llegar a ser un caos y mejor ir con 'patches' ?
> 

En realidad, eso tiene poco que ver con CVS: piensa en c�mo/cuando se 
producen conflictos...

Existen dos tipos de conflictos seg�n *tu* punto de vista, pero s�lo uno 
de ellos es visible por CVS.  Tenemos el conflicto sem�ntico, que se 
produce sistem�ticamente por mala comunicaci�n entre los miembros del 
equipo de desarrollo, y tenemos el conflicto textual que se produce 
simpre por mala comunicaci�n entre los miembros del equipo de desarrollo
;^D

El conflicto sem�ntico es un conflicto l�gico, como puede ocurrir si 
cambias un API sin avisar a nadie (ejemplo, un m�todo que requer�a dos 
par�metros, lo cambias y ahora necesita tres: todas las llamadas a esa 
funci�n en otras partes del c�digo entrar�n en conflicto con tu cambio). 
  CVS de esto no sabe nada.  Es importante que el an�lisis del sistema 
sea el adecuado para minimizar tanto los cambios de "firmas", como para 
minimiar su impacto, y es importante la comunicaci�n entre los miembros 
del equipo de desarrollo, para que tal tipo de cambio sea de 
conocimiento (y aceptado) por todo el grupo.

A CVS los �nicos conflictos que reconoce son los textuales: dos (o m�s) 
personas modifican a la vez porciones muy pr�ximas del mismo archivo. 
*ESTO* es, exclusivamente, lo que produce un conflicto en CVS que tendr� 
que ser tratado manualmente.  Ahora bien, lo primero que hay que 
preguntarse es porqu� dos personas a la vez andaban trasteando al mismo 
tiempo en la misma porci�n de archivo (lo que dec�a antes: en general, 
mala comunicaci�n entre los miembros del grupo) y, segundo, c�mo se 
puede esperar que tal circunstancia pueda ser tratada por ninguna 
herramienta de forma autom�tica (que no se puede).  En el caso concreto 
de la herramienta patch, justamente trabaja sobre diff que produce 
conflictos exactamente en las mismas circunstancias que CVS (ya que 
sobre diff/patch trabaja tambi�n CVS).  Resumiendo: con CVS te 
aparecer�n conflictos que habr� que resolver manualmente exactamente en 
las mismas circunstancias en que aparecer�an usando diff/patch.  �C�mo 
evitarlos?  Pues a veces no se puede pero, trabajando en un grupo bien 
comunicado, sobre una aplicaci�n bien dise�ada (encapsulaci�n, APIs 
estables, ficheros peque�os), normalmente se reducen a un m�nimo 
perfectamente entendible.

> 
>>>>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.
> 
> 
> Te veo muy tenso respecto a este tema (por tu respuesta a Alvaro=. Yo ahora 
> he montado els cvspserver para estos motivos:
> 

No, no estoy tenso.  Lo que pasa es que se trata de una pregunta de las 
que acaban resultando en largu�iiiiiiiisimas discusiones, siendo que la 
cosa es bien sencilla.

> - No debo entrar el password a cada operaci�n (si, ya se lo de auth RSA ya) 

...y cosas como ssh-agent, supongo, y que puedes usar una "firma" para 
uso exclusivo con CVS...

> - Me permite distinguir en los logs del sistema entre conexiones ssh y 
> conexiones cvs.
> 

�Es que hay alguna diferencia?  Una conexi�n ssh para ejecutar cvs es 
una conexi�n ssh igual que cualquier otra �o no?  Si te interesa 
mantener un log de las operaciones realizadas por CVS, �ste programa 
puede mantener sus propios logs.

> Por el tema seguridad, he visto que no tienes por qu� usar la misma 
> contrase�a CVS que para el sistema, con lo qual si se compromete algo ser� 
> el mismo repositorio, no el sistema entero.
> 

El problema estriba en que ni pserver ni cvs en s� mismo est�n dise�ados 
ni poco ni mucho ni nada con el fin de mantener ningun tipo de auditor�a 
de seguridad: es el sistema el que debe proporcionar esos servicios. 
Respecto a pserver, cualquiera que lo use debe tener en cuenta que est� 
abriendo, como m�nimo, a cualquiera de sus usuarios, acceso a la m�quina 
con el nivel de privilegios del usuario que ejecute el servicio (con 
suerte, igual no es root).  Por otra parte, en la generalidad de los 
casos, pserver se usa lanzado desde inetd, con su propia bater�a de 
problemas (el m�s habitual de los cuales es, por supuesto, el bloqueo de 
conexiones cuando alguien lanza un comando, digamos tag, contra los 
ochenta ficheros de su (mini)proyecto).

> A�n as�, cvspserver s�lo est� accesible des de la red local, tras un filtro 
> de paquetes Net-Filter y el TCP wrappers, creo que ser� suficiente. Para 
> conexiones exteriores segui� usando el metodo RSH=/usr/bin/ssh
> 

Eso es ver las cosas justamente al contrario de como hay que verlas 
(seg�n mi opini�n): muy posiblemente en tu servidor sshd ya est� en 
ejecuci�n, dispones de un cliente ssh en tu equipo y se permite 
encriptaci�n de canal, autenticaci�n y auditor�a, con un modelo de 
interacci�n que no es ni m�s dif�cil ni m�s engorroso que el que pueda 
proporcionar pserver.  Entonces �para qu� voy a poner *un servicio m�s*, 
que adem�s es un problema m�s que conocido? (por m�s que a fecha de hoy, 
en mi entorno, parezca que no me afecta).  Es el mismo caso que cuando 
veo, sin necesidad, usar telnet o las r* de Berkeley*1.  �Pero a santo 
de qu�?  sshd te cumple por ambos lotes, lo tienes que tener, si no es 
para eso para otras cosas, es muy sencillo de mantener y te evita un 
mont�n de problas (aunque hoy s�lo sean problemas potenciales).

> �Por qu� tanta alarma?
> 

No hay "alarma" por ning�n lado.  Simplemente he querido zanjar la 
discusi�n r�pidamente acudiendo a la intensidad de la respuesta (y si se 
admite, al principio de autoridad), pero veo que con poco �xito.

*1 Soy consciente de que hay casos en los que s� es obligado recurrir a 
telnet o las r*, hablo de la generalidad de los casos que yo conozco.
-- 
SALUD,
Jes�s
***
jesus_navarro@undominio.net
***