Node:Iniciando un repositorio, Next:, Previous:Anatomia de una distribucion CVS, Up:Administracion del Repositorio



Iniciando un 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:

  1. A�ada un grupo de Unix 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
    
  2. Haga que la propiedad y permisos del repositorio reflejen este nuevo grupo:
    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.