Si un desarrollo de software en UNIX ha de ser algo serio y no un mero pasatiempo de aficionados, es menester llevar un control de las versiones que se desarrollan, más aún si se pretende trabajar en equipos. En el universo de los S.O. Unix (Linux, BSD, FreeBSD, AIX, SCO, IrIX, Solaris) existe un invento muy útil para permitir guiar el desarrollo de una API, GUI ó SO inclusive el CVS, de poco uso en la Argentina pero no en el resto del planeta, es el estándar de facto del momento en los grupos de desarrolladores de software UNIX-semejante. Existen otras como la ineficiente SCCS y la comercial RCS, pero de todas la GNU CVS ha mostrado ser mucho más eficiente que sus predecesoras.

Un Cacho de Historia

CVS nace en 1989, época de saquéos en Rosario, de la mano de Brian Berliner a partir de unos "script" publicados en Usenet (puerto 119). Desde entonces, se han sucedido multitud de cambios realizados por un gran número de empresas pero principalmente por Cygnus Support (www.cygnus.com) y Cyclic Software (www.cyclic.com). En la practica la totalidad de los cambios recientes son debidos a Cyclic. Antiguamente CVS se apoyaba en la herramienta RCS (Revision Control System), pero por motivos de eficiencia, se ha eliminado dicha dependencia y CVS ya es parte oficial del proyecto GNU, además es usado por la mayoría de los grandes proyectos de soft libre del mundo (gcc, emacs, guile, gtk, gimp, gnome, linux, etc.).

Primeros pasos con CVS

Aunque CVS está diseñado para soportar desarrollos concurrentes de grandes sistemas de soft, eso no significa que no esté indicado para tareas simples, como el desarrollo de nuestros propios API. Desde el punto de vista del usuario CVS tiene un único ejecutable, el 'cvs' que sirve para realizar todas las operaciones. La interfaz CVS usa comandos en línea de órdenes.

La filosofía de trabajo en CVS es la siguiente, existe un ente llamado "repositor": la cuál es una jerarquía de directorios alojada en algún servidor, que puede ser incluso nuestra propia máquina, que contiene módulos a disposición de los clientes. Otro ente son los "módulos": árbol de directorios que forman parte del repositor, cuenta con un nombre identificador gracias al cual se puede bajar en forma selectivas fuentes

de él. Para crear un repositor en nuestra cuenta-hogar, primeramente debemos crear el directorio repositor, que llamaremos cvsuniverso, con:

mkdir ~/cvsuniverso

luego debemos decirle a CVS donde estará ubicado dicho repositor, que será el repositor por defecto, con

export CVSROOT=/home/universo/cvsuniverso
cvs init

En ese momento el CVS lanzará el editor por defecto (por lo general el VI) para que coloquemos un comentario. Esto se puede evitar con:

cvs -m "Experimentos" init

por otro lado si queremos usar otro repositor, diferente del 'por defecto', siempre debemos colocar como directiva '-d/..camino/nuevorepositor'. Una vez creado el repositor debemos crear el módulo y colocar en el los fuentes, supongamos que los fuentes se hallan en el directorio "ungs" entonces:

cd ungs
cvs import -m "Cometario bla bla.." ungs ChaosCompany Cosas

a continuación saldrá:

N ungs/cuarto.c
N ungs/primer.c
N ungs/quinto.c
N ungs/segundo.c
N ungs/tercero.c
N ungs/s10.c
N ungs/sexto.c
N ungs/s8.c
N ungs/s7.c
N ungs/s9.c
N ungs/lista.h
I ungs/lista.h~
N ungs/ordenar.c
N ungs/complex.c
N ungs/rprintf.c
I ungs/plist.c~
N ungs/plist.c

No conflicts created by this import

Esto nos indica que nuestros fuentes fueron copiados a nuestro repositor por defecto. Luego ya podemos borrar el directorio en cuestión. Una observación, "ungs" es el nombre del módulo al cuál se colocaran los fuentes, "ChaosCompany" es el nombre del creador y "Cosas" una etiqueta

identificativa. Es decir el formato en general es:

cvs import -m "mensaje" módulo creador etiqueta

Los pasos a seguir son ahora:

cd ..
rm -r ungs<----Se borra el directório temporario.
cvs checkout ungs <---nombre del directorio (módulo!)

y si todo salió bien debe aparecer:

cvs checkout: Updating ungs
U ungs/complex.c
U ungs/cuarto.c
U ungs/lista.h
U ungs/ordenar.c
U ungs/plist.c
U ungs/primer.c
U ungs/quinto.c
U ungs/rprintf.c
U ungs/s10.c
U ungs/s7.c
U ungs/s8.c
U ungs/s9.c
U ungs/segundo.c
U ungs/sexto.c
U ungs/tercero.c

Además de crearse el directorio ungs/ se crea el directorio ungs/CVS/ que contiene información relativa al repositor y estadísticas propias y No debe ser tocado sino el CVS se desubicaría. Supongamos que corregimos los errores en s10.c, podemos guardar nuestro resultado en el repositor con:

cvs commit -m "Bla bla..." s10.c

si por alguna causa borramos algún fuente por error basta con ingresar:

cvs update

y se recupera con la última versión. Para poder borrar un fuente completamente basta con ingresar.

rm s10.c
cvs remove s10.c
cvs commit

Con "commit" (o en su forma abreviada "ci") se hacen efectivos los cambios en el repositor. Para anexar un nuevo fuente a nuestro proyecto basta con hacer:

cvs add s20.c
cvs commit

Advertencia: No se pueden guardar, de esta forma, archivos binários ni imágenes en el módulo, para ello consulte el manual de usuario.

En cualquier momento podemos ver el estado de nuestras versiones con

cvs status

O en todo caso podemos ver la leyenda que deja cada desarrollador, para las futuras reparaciones con:

cvs log

y para un fuente en particular con cvs log s10.c, por ejemplo.

En el caso que se quiera trabajar en red hay que tomar el recaudo de indicarle al CVS que el repositor está en otra máquina para ello se ingresa, supongamos que estamos en el host "oscura" y el servidor cvs está en el host "clara".

export CVSROOT=":ext:universo@clara:/usr/local/cvsuniverso"
export CVS_RSH=/usr/local/bin/ssh

en este caso con "ext" se le dice al CVS que usaremos como shell el OpenSSH, como antes para copiar el módulo se hace:

cvs co ungs <------co==checkout! es una abreviatura
universo@clara's password: <-----pide autenticación
/usr/X11R6/bin/xauth: creating new authority file
/home/universo/.Xauthority
cvs server: Updating ungs
U ungs/complex.c
U ungs/cuarto.c
U ungs/lista.h
U ungs/ordenar.c
U ungs/plist.c
U ungs/primer.c
U ungs/quinto.c
U ungs/rprintf.c
U ungs/s10.c
U ungs/s7.c
U ungs/s8.c
U ungs/s9.c
U ungs/segundo.c
U ungs/sexto.c
U ungs/tercero.c

Este mecanismo tiene el problema de pedirnos la autenticación cada vez quue hagamos una operación con el servidor. Otro mecanismo, que evita las reiteradas autenticaciones, es el uso del "rsh" conocido como "pserver" que usa el puerto 2401, en este caso el repositor por defecto será:

export CVSROOT=":pserver:universo@clara:/usr/local/cvsuniverso"

sin ninguna instrucción más. Antes de cualquier operación se debe indicar que somos un usuario autorizado, entonces con ingresar:

cvs login

Se nos pedirá nuestra contrasena que será guardada en:

$HOME/.cvsroot

Para no preguntarnolas más en otros ingresos al server, luego podemos hacer todas las operaciones anteriores con el server. Al finalizar la seción se cierra con "cvs logout". El mecanismo remoto permite el uso de grupos de trabajos y operar con las "ramas". Lo normal cuando se desarrolla un soft es que se ramifique al menos en dos, una que corresponde a la versión estable y otra a la de desarrollo e innovación, para crear una rama basta con indicar:

cvs tag -b borrador_1_0

Cabe observar que se sustituye los puntos '.' por los guiones. La linea principal no se mezcla con la anterior, para poder extraer los fuentes del repositor basta con introducir:

cvs co -r borrador_1_0 borrador <---módulo

Para poder integrar los "parches" que estamos desarrollando a la rama principal lo podemos hacer con la directiva "-j" ("join"):

cvs update -j borrador_1_0
cvs commit

Por último CVS permite etiquetar nuestros proyectos con la directiva "tag" en el primer desarrollo sería:

cvs tag ungs_1_0

Para más detalles se puede consultar el "man" o en info del CVS, en Internet hay un sin número de ayudas (en inglés) sobre el CVS.