Copyright � 2002 Ismael Olea, Ignacio Arenaza
Permiso para copiar, distribuir o modificar este documento de acuerdo a los terminos de la Licencia de Documentacion Libre de GNU (GNU Free Documentation License), Version 1.1 o posterior, publicada por la Free Software Foundation. Este documento no contiene Secciones Invariantes (with no Invariant Sections), ni Textos de Portada (with no Front-Cover Texts) ni Textos de Contraportada (with no Back-Cover Texts).
| Historial de revisiones | |
|---|---|
| Revisi�n $Revision: 1.1 $ | $Date: 2002/10/09 19:19:17 $ |
| Submitted. | |
Resumen
Breve tutorial introductorio al uso de CVS, con especial �nfasis en el uso de la parte cliente de CVS. Se a�aden algunas referencias a frontales adicionales al cliente tradicional, as� como enlaces a tutoriales m�s amplios y detallados. La parte servidora de CVS se trata tambi�n con una cierta profundidad.
Tabla de contenidos
- 1. Introducci�n
- 2. Terminolog�a CVS
- 3. Invocar a CVS
- 4. Configuraci�n
- 4.1. La autenticaci�n
- 5. Uso
- 6. C�mo configurar un servidor y c�mo incorporar nuevos m�dulos al repositorio.
- 7. Bibliograf�a
- 8. Interfaces de usuario para CVS
- 9. Otros recursos CVS interesantes
- 10. Otros recursos CVS m�s avanzados
- 11. Licencia
CVS es un sistema de mantenimiento de c�digo fuente (grupos de ficheros en general) extraordinariamente �til para grupos de desarrolladores que trabajan cooperativamente usando alguna clase de red.
Para ser m�s concreto, CVS permite a un grupo de desarrolladores trabajar y modificar concurrentemente ficheros organizados en proyectos. Esto significa que dos o m�s personas pueden modificar un mismo fichero sin que se pierdan los trabajos de ninguna. Adem�s, las operaciones m�s habituales son muy sencillas de usar.
Como a�adido a lo anterior, CVS guarda todas las versiones antiguas de los ficheros. Esto permite recuperar en cualquier momento versiones anteriores a la actual.
Dado que trabaja con ficheros ASCII es igual de �til para trabajar con c�digo fuente de programas o con toda clase de documentos siempre que su formato sea completamente de texto, como pueden ser ficheros sgml/html/xml.
Este documento es una referencia inmediata para trabajar con CVS. A poco que le saque partido necesitar� consultar otro m�s extenso y detallado. Sin embargo el 80% o m�s de las acciones que desarrollan los usuarios de CVS est�n documentadas en este art�culo.
Con CVS puede trabajarse de forma local (repositorio y copias de trabajo en el mismo sistema) o remota (el repositorio est� en un sistema servidor y la copia local en otro que es cliente del primero).
En este art�culo s�lo prestar� atenci�n al modo de trabajo remoto, que es el mas utilizado habitualmente en los proyectos de software libre, por su modus operandi habitual.
Para que no se pierda, un brev�simo vocabulario:
- repositorio
Jerarqu�a de directorios alojada en el servidor CVS que contiene diferentes m�dulos a disposici�n de los usuarios.
- m�dulo
�rbol de directorios que forma parte del repositorio. Cuenta con un nombre identificador gracias al cual podremos trabajar con �l de forma selectiva.
CVS es un programa que se invoca desde int�rpretes de �rdenes. Seg�n cual sea su configuraci�n (desde el punto de vista de las diferentes formas de autenticaci�n, que veremos en un momento) lo podr� usar en procesos por lotes sin ning�n problema.
Un aspecto que debe tener en cuenta (sobre todo si este es el primer documento que lee sobre CVS) es que CVS tiene par�metros para cada una de sus �rdenes. Para conocerlas tiene dos m�todos: invocar CVS como cvs help o consultar la ayuda de su p�gina del manual.
Puede usar varios ficheros de configuraci�n que CVS reconocer� y usar�.
Entre otros, tenemos los siguientes:
- ~/.cvsignore
que contiene los sufijos de los ficheros que no nos interesa que CVS controle. Por ejemplo podemos tener:
*.aux *.dvi *.ps *.log
si los ficheros de este m�dulo son principalmente documentos escritos en (La)TeX, ya que las extensiones mostradas arriba corresponden a los diferentes ficheros temporales creados durante el procesado del fichero fuente original para obtener el fichero listo para impresi�n.
As� evitamos contaminar el repositorio con ficheros que realmente no es necesario que est�n controlados por CVS.
- ~/.cvsrc
que contiene aquellos par�metros que CVS usar� cada vez que se invoque una determinada orden, de forma autom�tica. Por ejemplo:
update -Pd diff -uw cvs -z 3
Significa que queremos que cuando usemos la orden update, autom�ticamente y sin que tengamos que escribir nada m�s, se a�adan los par�metros -Pd (borrar los directorios vac�os tras la actualizaci�n y crear los directorios del repositorio que no existan en la copia local). Algo similar ocurre con la orden diff.
La �ltima l�nea es especial, en el sentido de que no hay una orden cvs. Se trata de la forma en que se indican par�metros globales del propio CVS, no espec�ficos de ninguna orden.
Al trabajar en remoto con CVS pueden elegirse varias alternativas de autenticaci�n (es decir, de demostrar al servidor que somos quienes decimos ser).
Las m�s utilizadas son v�a pserver y v�a ssh (aunque existen otras dos formas al menos: v�a rsh, totalmente desaconsejada por motivos de seguridad, y v�a Kerberos, que no es habitual por necesitar toda la infraestructura de seguridad de Kerberos).
Deber� elegir alguna de estas t�cnicas en funci�n de sus necesidades, en caso de que no vengan impuestas de forma externa (por ejemplo, porque el repositorio ya existe y el tipo de acceso ya ha sido elegido previamente).
Para que CVS use este modo de autenticaci�n se deben usar estas variables de entorno:
export CVSROOT=:ext:[email protected]:/var/lib/cvs export CVS_RSH=/usr/bin/ssh
donde USUARIO es el nombre de usuario que tiene acceso al repositorio, cvs.dominio.org, es el nombre del servidor donde se aloja el repositorio, /var/lib/cvs es el directorio del servidor en el que est� el repositorio y /usr/bin/ssh es la ruta completa al ejecutable de ssh.
Tenga en cuenta que, usando esta t�cnica, tendr� que autenticarse (es decir, suministrar su contrase�a) cada vez que ejecute alguna orden de CVS (a menos que use autenticaci�n con clave p�blica RSA/DSA para ssh).
La ventaja de usar ssh como m�todo de autenticaci�n es que las comunicaciones con el servidor CVS van completamente cifradas, tanto la autenticaci�n como los datos que intercambiemos con el servidor (cosa que no ocurre con el siguiente m�todo).
El inconveniente de este m�todo de autenticaci�n es que deber� crear cuentas de usuarios locales en el servidor CVS con posibilidad de inicio de sesi�n (shell v�lido) para todos aquellos usuarios remotos que necesiten acceso al servidor, lo cual implica un acceso m�s amplio al equipo donde se ejecuta el servidor CVS que el mero acceso al servicio CVS.
Si no necesitamos que los datos que se intercambian con el servidor vayan cifrados y nos basta con una autenticacion relativamente segura, podemos utilizar el m�todo pserver.
La ventaja de este m�todo sobre el anterior es doble en este caso:
No require cuentas de usuario en el servidor CVS para cada uno de los clientes, ni permite ning�n tipo de acceso adicional en el servidor.
Es un esquema facil de configurar y administrar de forma moderadamente segura (aunque es mucho menos segura que el m�todo via ssh, desde el punto de vista de secuestro de contrase�as de usuario CVS).
Para poder usar este tipo de autenticaci�n, deber� usar una variable de entorno similar a esta:
export CVSROOT=:pserver:[email protected]:/var/lib/cvs
donde USUARIO es nuestro nombre de usuario, cvs.dominio.org es el servidor que aloja al repositorio y /var/lib/cvs es el directorio del servidor en el que est� el repositorio.
Si usa esta t�cnica, antes de poder trabajar con CVS deber� autenticarse ante el servidor. Eso se hace con la orden cvs login:
$ cvs login
CVS le pedir� la contrase�a del usuario que haya configurado en la variable de entorno mencionada arriba. Si la contrase�a es correcta CVS guardar� la informaci�n que necesita en el fichero ~/.cvspass y no tendr� que volver a autenticarse.
Si por alg�n motivo quisiera �cerrar la sesi�n� CVS (esto es, dejar de trabajar con ese servidor CVS o con ese repositorio) bastar� con hacer:
$ cvs logout
Por supuesto, nada impide usar ambos m�todos para el acceso al servidor (v�a ssh y v�a pserver) de forma conjunta, de forma que ciertos usuarios usen uno de los m�todos y otros usuarios el otro. Esto es especialmente interesanta para el acceso adminisitrativo al servidor CVS, dado que el m�todo pserver no es lo suficientemente seguro en este caso.
A continuaci�n se propone una sencilla metodolog�a de trabajo con CVS para evitar trabajos redundantes. Piense por ejemplo en la eliminaci�n de erratas o errores en documentos o en c�digo fuente.
Antes de cada sesi�n de trabajo es conveniente hacer cvs update -Pd para asegurarnos de que disponemos de las �ltimas modificaciones registradas en el repositorio.
Justo al acabar cada sesi�n de trabajo es conveniente hacer cvs commit (se puede abreviar en cvs ci) para que todas nuestras modificaciones se registren en el repositorio.
Para crear una copia de trabajo local del m�dulo CVS deseado debemos usar la orden cvs checkout(abreviable como cvs co):
$ cd padre-de-directorio-donde-se-alojar�-el-m�dulo
$ cvs checkout nombre-del-m�dulo
Esto crear� una jerarqu�a de directorios donde se almacenar� la copia local de trabajo el m�dulo. Este paso s�lo hay que hacerlo una vez por cada m�dulo.
A partir de este momento no es necesario configurar las variables de entorno porque CVS sabe a qu� repositorio pertenece el m�dulo con s�lo examinar los subdirectorios CVS. No se debe modificar nunca esos subdirectorios a mano. De lo contrario CVS perder� la pista de a que m�dulo pertenecen los ficheros, cu�les son las versiones de la copia local, etc.
Cuando queramos actualizar la copia local de trabajo del m�dulo con los cambios que hayan podido hacer otros usuarios y que est�n recogidos en el repositorio deberemos hacer:
$ cd directorio-del-m�dulo
$ cvs update -Pd
Se usa la orden commit (o su equivalente ci):
$ cd directorio-del-m�dulo
$ cvs commit
Tras lo cual el sistema mostrar� la pantalla de un editor de textos (el que tengamos configurado como nuestro favorito en la variable de entorno EDITOR) para que introduzcamos una descripci�n, lo m�s significativa posible, del conjunto de cambios realizados en el m�dulo desde el �ltimo commit.
Habr� ocasiones en las que tengamos que resolver los conflictos que surjan entre diferentes versiones de un m�dulo o fichero del mismo (recuerde que puede haber m�ltiples personas trabajando de forma concurrente sobre el mismo m�dulo) para que CVS contin�e trabajando. Estos conflictos son normales y ocurren cuando dos o m�s personas modifican a la vez exactamente la mismas partes de un fichero.
El procedimiento es simple:
CVS se quejar� de un fichero al hacer un update o un commit.
Editamos ese fichero y encontraremos marcas del tipo:
[...] >>>>>>>>>>>>>> texto-opci�n-1 =========== texto-opci�n-2 <<<<<<<<<<<<<< [...]
El texto entre marcas es el que produce el conflicto. Hay que elegir qu� modificaci�n nos gusta y borramos todo lo dem�s.
Si no quedan m�s conflictos volvemos a hacer el commit o update.
No olvide que CVS controlar� s�lo los ficheros que se hayan descargado inicialmente desde el repositorio. Cualquier otro fichero o directorio de la jerarqu�a del m�dulo CVS ser� ignorado.
Si quiere a�adir un nuevo fichero o directorio al m�dulo CVS hay que seguir los siguientes pasos (ademas de crear o copiar el propio fichero al m�dulo, por supuesto):
$ cd directorio-del-m�dulo
$ cvs add fichero
pero si el fichero es binario hay que tener la precauci�n de hacer:
$ cd directorio-del-m�dulo
$ cvs add -kb fichero
�Por qu�?, se preguntar� el lector m�s intr�pido. Resulta que CVS usa varias variables (en realidad son de RCS, que funciona por debajo de CVS). Si el fichero es binario es posible que se d� una combinaci�n de bytes que coincidan con alguna de estas variables. Si as� fuera, RCS/CVS modificar�a el contenido y lo corromper�a. Tambi�n se debe a que el sistema de c�lculo de diferencias que usan estos sistemas no est� dise�ado para trabajar con informaci�n binaria. Si se obra equivocadamente es probable que corrompamos los datos.
Tambi�n quiero se�alar que si bien se pueden gestionar ficheros binarios, no se har� control de versiones de los mismos. S�lo se guardar� la �ltima versi�n (al no disponer CVS de la funcionalidad necesaria para calcular diferencias de ficheros binarios).
Tras la orden cvs add hay que hacer ejecutar de nuevo la orden cvs commit para incluir los nuevos ficheros en el repositorio CVS.
Para eliminar un fichero del m�dulo CVS hay que hacer lo siguiente una vez borrado el fichero de la copia local de trabajo (se puede usar cvs rm como abreviatura):
$ cd directorio-del-m�dulo
$ cvs remove fichero
En cambio, si queremos borrar f�sicamente los ficheros a la vez que los eliminamos del m�dulo deberemos usar:
$ cd directorio-del-m�dulo
$ cvs remove -f fichero
Para configurar un servidor CVS con acceso remoto hay b�sicamente tres formas (cuatro en las versiones recientes, pero no conozco ning�n cliente de autenticaci�n por medio de GSSAPI en el momento de escribir esto, asi que nos quedamos con los tres originales).
- rsh/ssh
Esta primera opci�n implica tener una cuenta equivalente en el servidor CVS y no hace falta tocar ni inetd.conf ni ejecutar el servicio pserver. La seguridad de esta soluci�n es nula a menos que se use ssh como sustituto de rsh.
- pserver
La segunda opci�n usa una cuenta gen�rica (la misma para todo el mundo o varias diferentes si se desean, pero no son cuentas con acceso local al servidor), necesita activar pserver desde inetd.conf (o xinetd.conf, si se usa este �ltimo). La seguridad es superior al m�todo precedente en caso de usar rsh pero inferior al uso de ssh. La gran ventaja de este m�todo es que los usuarios de CVS no necesitan ning�n tipo de acceso local al servidor.
- Kerberos
Kerberos queda fuera de juego a mi modesto entender, ya que la infraestructura necesaria para usar este m�todo de autenticaci�n simplemente no tiene sentido para uso de CVS fuera de un mismo dominio administrativo (sin contar la complejidad de instalaci�n y operaci�n de un dominio Kerberos).
En la pr�ctica, buena parte de los servidores CVS p�blicos usan la opci�n de pserver, al no ser necesario dar de alta cuentas de sistema a los usuarios en el servidor. Si el acceso va a ser mucho mas restringido (un peque�o grupo estable y de confianza), la opci�n de usar ssh es claramente preferible.
Si optamos por el m�todo pserver, deberemos a�adir una l�nea como la siguiente en el fichero inted.conf:
cvspserver stream tcp nowait root /usr/sbin/tcpd /usr/bin/cvs
-b /usr/bin -f --allow-root=/var/lib/cvs pserver
(todo en una sola l�nea, por supuesto; aqu� se muestra partido en dos por cuestiones de espacio). El valor /var/lib/cvs corresponde al directorio donde ubicaremos el repositorio en el servidor CVS y que denotaremos de ahora en adelante por la variable de entorno $CVSROOT.
Hay que asegurse tambi�n, en caso de estar usando TCP Wrappers (como es el caso del ejemplo) de que permitimos el acceso al servicio CVS (en el fichero /etc/hosts.allow con una l�nea como la siguiente. De lo contrario se van a rechazar las conexiones.
cvs: ALL
El segundo punto a tener en cuenta es qui�n tiene acceso a los repositorios CVS y qu� tipo de operaciones se pueden realizar. Basicamente, una vez creado el repositorio, se suelen realizar dos grandes grupos de operaciones:
Adici�n/actualizaci�n de ficheros del repositorio (implica acceso en modo escritura). Aqui van los commit, add, remove y compa�ia.
Actualizaciones en el cliente/creaci�n de diferencias. Esto s�lo implica acceso en modo lectura. Aqui van los checkout, update, diff y compa�ia.
El acceso en modo escritura al respositorio s�lo se debe otorgar a las personas estrictamente necesarias, ya que en teor�a el acceso al sistema se abre potencialmente bastante.
El acceso en modo lectura no plantea problemas (salvo de carga de la maquina si los checkout / diff / update son masivos).
A continuaci�n se muestran los pasos a realizar para la creaci�n inicial del repositorio CVS.
Configurar /etc/inetd.conf para que lance el servidor pserver como se ha comentado arriba, en caso de usar el m�todo de acceso pserver.
Definir una cuenta administrativa local para CVS (en el ejemplo se llamar� cvsadm) que ser� quien administre CVS. Esta cuenta ser� la propietaria de los ficheros de control del repositorio y quien pueda crear nuevos m�dulos en el mismo. Aprovecharemos para crear un grupo llamado cvs para gestionar m�s c�modamente los permisos del repositorio y sus m�dulos.
El usuario cvsadm deber� ser parte del grupo cvs. Sin embargo esta cuenta no tienen porque tener acceso local al sistema en caso de usar el m�todo de acceso pserver.
Crear el repositorio en local en el servidor (en $CVSROOT), ejecutando las ordenes (si queremos colocar el respositorio en /var/lib/cvs):
CVSROOT=/var/lib/cvs; export CVSROOT mkdir -p $CVSROOT cvs init
El repositorio conviene crearlo como root y tratarlo, desde el punto de vista de los permisos, como si fuera el directorio /etc. Todos sus ancestros s�lo deberian ser escribibles por root. El propio $CVSROOT deber�a ser escribible por el administrador del servidor CVS (cvsadm, como hemos indicado m�s arriba). NADIE MAS deber�a tener permisos de escritura en dicho directorio.
Esto se hace asignando su propiedad al usuario cvsadm y haciendo al grupo cvs el grupo de $CVSROOT. Adem�s, ser�a conveniente que $CVSROOT tuviera activado el bit SGID, para que los subdirectorios y ficheros que se creen debajo hereden el grupo principal del fichero o directorio (e indirectamente, por el ajuste del valor de umask que hace el propio CVS en modo pserver, el permiso de escritura para el grupo cvs y que tenga as� control sobre todo lo que se introduzca all�). En resumen, $CVSROOT deber�a tener los permisos:
drwxr-s--- 10 cvsadm cvs 1024 Oct 2 12:31 $CVSROOT
El usuario cvsadm> ser� el propietario de los ficheros que haya en $CVSROOT/CVSROOT. El �nico fichero que es necesario que tenga permisos de escritura para los usuarios de CVS es $CVSROOT/CVSROOT/history. El resto, deben tener s�lo permiso de lectura. Esto es:
$CVSROOT/CVSROOT: drwxr-x--- 2 cvsadm cvs 1024 Oct 2 12:52 CVSROOT $CVSROOT/CVSROOT/history: -rw-rw---- 1 cvsadm cvs 9609 Oct 2 13:01 history $CVSROOT/CVSROOT/commitlog: -rw-rw---- 1 cvsadm cvs 9609 Oct 2 13:01 commitlog (*) $CVSROOT/CVSROOT/log.pl: -r-xr-x--- 1 cvsadm cvs 9609 Oct 2 13:01 log.pl (*) $CVSROOT/CVSROOT/*: -r--r----- 1 cvsadm cvs 9609 Oct 2 13:01 (el resto de ficheros)
(*) Esto s�lo es necesario si se va a usar la caracteristica loginfo con el script log.pl o similares. En cualquier caso, no deberia ser problem�tico.
Incorporar al grupo cvs los diferentes usuarios locales que van a representar a los usuarios remotos de pserver. En concreto, en mi sistema, existen cvsadm, cvsuser y anoncvs, que representan respectivamente al administrador del servidor CVS, a los usuarios CVS con permiso de escritura en el repositorio (previa autenticaci�n) y a los usuarios con acceso s�lo lectura en modo an�nimo.
La idea de este grupo (como se ha comentado arriba) es poder asignar los permisos locales a los ficheros de forma que tanto el administrador como los usuarios tengan acceso a ellos.
Si se va a usar pserver, es muy importante que los usuarios que tengan que ver con CVS (cvsadm, anoncvs y cvsuser) no puedan tener acceso local al servidor (esto es, poner una contrase�a no v�lida, un shell no v�lido, etc.)
Los m�dulos iniciales para cada proyecto (manual, como, programa, etc.) los debe crear el administrador del servidor CVS. Luego los puede usar cualquiera. As� garantizamos que los permisos son los adecuados, y que todo esta �controlado y en orden�.
Para funcionalidades adicionales (envio de mensaje de corre cada vez que se hace un commit, actualizacion de un log de commit en el repositorio, publicacion en el web del estado del repositorio, etc.) el propio administrador del servidor CVS se puede encargar de todo. Todo lo necesario esta en la documentaci�n oficial de CVS.
Todo lo anterior (especialmente el tema de permisos, usuarios necesarios, etc.) son conclusiones m�as despues de leer la documentacion de CVS y su FAQ. No est� indicado en ning�n sitio que se deba hacer exactamente as�, ya que s�lo se dan consejos muy generales y bastante dispersos por toda la documentaci�n. Con esto quiero decir que habr�a que hacer un an�lisis un poco m�s profundo sobre el posible impacto de seguridad.
En este caso, los usuarios de CVS son directamente usuarios del sistema. Por tanto, el administrador del sistema donde resida el servidor CVS debe dar de alta los usuarios normales y habilitar los permisos adecuados en el repositorio (y sus diferentes ficheros) para que puedan llevar a cabo el tipo de acceso deseado.
En este caso, tenemos que usar los ficheros $CVSROOT/CVSROOT/passwd $CVSROOT/CVSROOT/readers $CVSROOT/CVSROOT/writers . El primero de ellos sirver para indicar que usuarios remotos tienen acceso al repositorio y el segundo y tercero indican qu� usuarios de entre los anteriores tiene acceso en modo s�lo lectura y cu�les en modo lectura/escritura, respectivamente.
El formato del primero de ellos es similar al de los ficheros de contrase�as de Apache y de hecho se puede crear y manipular con la herramienta htpasswd. Decimos similar porque no es exactamente igual, al diponer de un tercer campo opcional que nosotros si usaremos. Veamos un ejemplo:
cvsadm:8BQYT0o1J7FI6:cvsadm anoncvs: hermes-team:8Ba2dFouJkxI6:cvsuser lucasiano:gA7sdFouJk9X6:cvsuser
En el ejemplo anterior tenemos cuatro usuarios remotos, pero en realidad s�lo tres usuarios locales. Los usuarios �remotos� son cvsadm, anoncvs, hermes-team y lucasiano. Estos son los nombres de usuario que se usar�n durante el proceso de autenticaci�n.
Sin embargo, una vez superada la autenticaci�n correctamente (el segundo campo del fichero es la contrase�a cifrada con el m�todo crypt est�ndar; si no existe, como en el caso del usuario anoncvs, valdr� cualquier contrase�a), se usar�n los usuarios que se indican en el tercer campo para el acceso local a los ficheros del repositorio. Esto es, el usuario remoto lucasiano en realidad ser� el usuario local cvsuser en el servidor y por tanto tendr� acceso a los ficheros y directorios a los que pueda acceder dicho usuario. En caso de no existir este tercer valor, el nombre de usuario remoto y el local ser�n el mismo.
Esta funcionalidad es muy interesante, ya que nos permite crear �nicamente una cuenta de usuario local en el servidor por cada tipo de acceso diferente necesario, y agregar despu�s cuantas cuentas remotas queramos y mapearlas al usuario local correspondiente. Como el fichero donde se realiza el mapeo es $CVSROOT/ROOT/passwd y este fichero est� disponible a trav�s del propio CVS, el administrador del servidor CVS no necesita permisos de administrador global de la m�quina donde este ubicado el repositorio para dar de alta nuevos usuarios de CVS. N�tese que en este caso, el fichero con las contrase�as viaja sin cifrar por la red, con lo cual se recomienda usar el m�todo de acceso ssh para este tipo de operaciones).
Para crear nuevos usuarios CVS podemos usar la orden htpasswd de Apache:
export CVSROOT=:ext:[email protected]:/var/lib/cvs export CVS_RSH=/usr/bin/ssh cd directorio-temporal-de-trabajo cvs checkout CVSROOT cd CVSROOT htpasswd passwd usuario-nuevo (*) New password: no-se-ve-mientras-se-escribe Re-type new password: no-se-ve-mientras-se-escribe vi passwd (**) cvs add passwd (*) y (***) cvs commit
(*) Si fuese el primer usuario del repositorio, el fichero passwd no existir�, y por tanto ser� necesario usar la opci�n -c de la orden htpasswd. De igual modo, habr� que indicar a CVS que existe un nuevo fichero llamado passwd para que lo tenga en cuenta y lo a�ada al repositorio al hacer el commit.
(**) Si se desea la funcionalidad de mapear el usuario remoto a un usuario local concreto, se puede editar el fichero a mano y a�adir el tercer campo, separ�ndolo del segundo por ':'.
(***) Para que esto funcione es necesario haber incluido el nombre del fichero passwd en el fichero $CVSROOT/checkoutlist previamente. (no se aconseja por motivos de seguridad a menos que el acceso administrativo a CVSse realice por medio de ssh, como se ha comentado m�s arriba y se ha hecho en el ejemplo mostrado).
Hemos mencionado m�s arriba los ficheros $CVSROOT/CVSROOT/writers y $CVSROOT/CVSROOT/readers. El proposito de ambos es poder delimitar a�n m�s el tipo de acceso permitido a los usuarios remotos. Si un nombre de usuario aparece en el fichero $CVSROOT/CVSROOT/writers este usuario tendr� acceso a las operaciones que impliquen modificaciones al repositorio. Este fichero contiene simplemente el nombre de los usuarios �remotos�, uno por l�nea, que tienen este tipo de acceso:
cvsadm hermes-team lucasiano
Si por el contrario aparece en el fichero $CVSROOT/CVSROOT/readers, s�lo tendr� acceso en modo lectura y no podr� hacer ning�n cambio en el repositorio. El formato es id�ntico al fichero anterior.
En caso de que aparezca en ambos ficheros, obtiene acceso de s�lo lectura. En caso de que no existan ninguno de los dos ficheros, el usuario obtiene acceso de escritura, as� que aseg�rese de crearlos durante la configuraci�n inicial del repositorio (no vienen creados de serie).
Por �ltimo, hay que tener muy presente que el control de acceso a los m�dulos se hace en base a los permisos de los directorios y ficheros del repositorio. Por tanto, si se quieren m�dulos con usuarios completamente independientes, habr� que extender el esquema usuarios/grupos locales aqu� presentado y jugar con los permisos. Esto supone una cierta complicacion para el administrador tanto del sistema como del repositorio CVS.
Para a�adir nuevos modulos al respositorio, la operaci�n debe ser llevada a cabo por el administrador del mismo. Para ello se usa la orden cvs import que le indica a CVS que debe crear una copia en el respositorio del conjunto de ficheros del directorio actual.
Por ello, para importar un nuevo m�dulo al respositorio debemos situarnos primero en el directorio ra�z del m�dulo donde est�n los ficheros del mismo y ejecutar la orden:
cvs import nombre-m�dulo etiqueta-vendedor etiqueta-versi�n
Donde:
nombre-m�dulo: es el nombre que le queremos dar al nuevo m�dulo.
etiqueta-vendedor: es el nombre que usa CVS para etiquetar la rama que crea con la importaci�n. Puede ser una cadena cualquiera de letras, n�meros y subrayados.
etiqueta-versi�n: es el nombre que usa CVS para etiquetar la versi�n concreta que se crea con esta importaci�n. Puede ser una cadena cualquiera de letras, n�meros y subrayados.
Por un lado hay un complet�simo fichero info dedicado a CVS, que es la documentaci�n oficial de mismo. Si usa GNU/Linux es muy probable que ya lo tenga instalado en su sistema.
Por otro lado en http://cvsbook.red-bean.com/ est� disponible otro libro documentando CVS.
He aqu� algunas interfaces de usuario para CVS, en mayor o menor estado de desarrollo. Todas ellas se pueden encontrar en http://freshmeat.net/.
pharmacy: Una interfaz GNOME para CVS, disponible en http://pharmacy.sourceforge.net/. Se encuentra aun en un estado de desarrollo bastante temprano y no se actualiza desde hace casi un a�o en el momento de escribir esto. Aqu� se puede ver un pantallazo del aspecto de su pantalla principal:
cvsgui: Una interfaz multiplataforma para CVS escrita en C++ (anteriormente conocida como gCVS), disponible en http://sourceforge.net/projects/cvsgui/. Su pantalla principal,
y el visor de ramas y versiones de los ficheros:
tkcvs: Interfaz gr�fica para CVS escrita en Tcl/Tk muy establecida y estable, disponible en http://www.twobarleycorns.net/tkcvs.html. El pantallazo de su ventana principal,
el navegador de m�dulos disponibles en el repositorio,
y el visor de ramas y versiones de los ficheros:
cervisia: Interfaz gr�fica KDE para CVS, disponible en http://cervisia.sourceforge.net/ . El pantallazo de su ventana principal,
el visor de ramas y revisiones de los ficheros:
el visor de anotaciones
y el visor gr�fico de diferencias:
lincvs: Interfaz gr�fica para CVS que usa la biblioteca grafica Qt, disponible en http://www.lincvs.org/. Su pantalla principal:
PCL-CVS: extensi�n de (X)Emacs que permite manipular ficheros gestionados con CVS de forma autom�tica y transparente, disponible como parte de XEmacs, y como parte del propio CVS.
La p�gina del propio CVS que ahora est� en http://www.cvshome.org/.
cvs2cl.pl: que es una herramienta para crear ficheros Changelog al estilo GNU y que puede encontrarse en http://www.red-bean.com/cvs2cl/
cvsadmin: Herramienta para administrar las cuentas de un repositorio, disponible en http://www.cooptel.qc.ca/~limitln/cvsadmin/
cvsauth: conjunto de parches para CVS que sirven para autenticar usuarios sin tener que ejecutar en el servidor CVS como root. A�ade adem�s cifrado SSL en las conexiones pserver tradicionales. Disponible en http://cvsauth.sourceforge.net/
Permiso para copiar, distribuir o modificar este documento de acuerdo a los terminos de la Licencia de Documentacion Libre de GNU (GNU Free Documentation License), Version 1.1 o posterior, publicada por la Free Software Foundation. Este documento no contiene Secciones Invariantes (with no Invariant Sections), ni Textos de Portada (with no Front-Cover Texts) ni Textos de Contraportada (with no Back-Cover Texts).