Node:Iniciando un repositorio, Next:El servidor de autentificacion de contrasen~as, Previous:Anatomia de una distribucion CVS, Up:Administracion del Repositorio
Una vez que el ejecutable CVS est� instalado en su sistema, podr� empezar
a usarlo en seguida como cliente para acceder a repositorios remotos, siguiendo
los procedimientos descritos en Una introduccion a CVS. Sin embargo,
si quiere servir revisiones desde su m�quina, tendr� que crear un repositorio
en ella. La orden para hacerlo es
floss$ cvs -d /usr/local/nuevorepos init
donde /usr/local/nuevorepos
es la ruta a donde usted quiera que est�
el repositorio (por supuesto, deber� tener permiso de escritura en ese
directorio, lo que podr�a implicar ejecutar la orden como root). En cierto
modo puede parecer poco intuitivo que la localizaci�n del repositorio nuevo se
especifique antes de la suborden init en lugar de despu�s de �l, pero usando
la opci�n -d sigue siendo consistente con otras �rdenes CVS.
La orden acabar� silenciosamente despu�s de ejecutarse. Vamos a examinar el
nuevo directorio:
floss$ ls -ld /usr/local/nuevorepos drwxrwxr-x 3 root root 1024 Jun 19 17:59 /usr/local/nuevorepos/ floss$ cd /usr/local/nuevorepos floss$ ls CVSROOT floss$ cd CVSROOT floss$ ls checkoutlist config,v history notify taginfo,v checkoutlist,v cvswrappers loginfo notify,v verifymsg commitinfo cvswrappers,v loginfo,v rcsinfo verifymsg,v commitinfo,v editinfo modules rcsinfo,v config editinfo,v modules,v taginfo floss$
El �nico subdirectorio del repositorio nuevo - CVSROOT/ - contiene varios ficheros de administraci�n que controlan el comportamiento de CVS. M�s adelante examinaremos esos ficheros uno a uno; por ahora, nuestro objetivo s�lo es conseguir que el repositorio funcione. En este caso, "funcionar" significa que los usuarios puedan importar, actualizar, obtener copias de trabajo y enviar cambios a los proyectos.
No hay que confundir la variable de entorno CVSROOT introducida en Una introduccion a CVS con este subdirectorio CVSROOT del repositorio. No tienen
nada que ver - es una coincidencia desafortunada que compartan el mismo
nombre. La primera es una forma de evitarles a los usuarios tener que teclear
-d <situaci�n-del-repositorio>
cada vez que usen CVS; el segundo
es el directorio de administraci�n de un repositorio.
Una vez que el repositorio se haya creado, deber� ocuparse de sus permisos. CVS no requiere de ning�n permiso est�ndar particular o sistema de propiedad de ficheros; simplemente necesita acceso de escritura al repositorio. Sin embargo - en parte por razones de seguridad, pero sobre todo por su propia salud como administrador - recomiendo encarecidamente que siga los siguientes pasos:
cvs
a su sistema. Cualquier usuario que
necesite acceder al repositorio deber�a estar en el grupo. Por ejemplo,
la l�nea del fichero /etc/group
de mi m�quina es:
cvs:*:105:kfogel,sussman,jimb,noel,lefty,fitz,craig,anonymous,jluis
floss$ cd /usr/local/nuevorepos floss$ chgrp -R cvs . floss$ chmod ug+rwx . CVSROOT
Ahora cualquiera de los usuarios listados en el grupo podr� empezar un
proyecto ejecutando cvs import
como se describi� en
Una introduccion a CVS. Las �rdenes "checkout", "update" y "commit"
tambi�n deber�an funcionar. Tambi�n podr�n entrar en el repositorio desde
localizaciones remotas usando el m�todo :ext:
, asumiendo
que tienen acceso por rsh o ssh a la m�quina del repositorio.
(Se habr� percatado de que las �rdenes "chgrp" y "chmod" en el ejemplo de
arriba le dieron acceso de escritura a un usuario llamado anonymous
,
que no es lo que uno esperar�a. La raz�n es que incluso los usuarios
an�nimos y de s�lo lectura del repositorio necesitan acceso de escritura
a nivel del sistema, para que sus procesos CVS puedan crear ficheros de
bloqueo temporales dentro del repositorio. CVS no asegura la restricci�n
de "s�lo lectura" del acceso an�nimo por medio de permisos de ficheros Unix
sino por otros medios, de lo que se hablar� en Acceso anonimo.)
Si su repositorio est� destinado a servir proyectos al p�blico en general, en cuyo caso los contribuidores no tendr�n necesariamente cuentas en la m�quina del repositorio, deber�a configurar ahora el servidor de autentificaci�n de contrase�as (see El servidor de autentificacion de contrasen~as). Es necesario para acceso an�nimo de s�lo lectura, y seguramente sea la manera m�s f�cil de asegurar acceso al env�o de cambios a ciertas personas sin tener que darles cuentas completas en la m�quina.