Temas
Resumen
El
presente informe presenta los fundamentos en que se basa CVS como sistema de
mantenimiento de ficheros en general, que 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.
Este documento es una referencia inmediata para trabajar con CVS. Luego de explicar su principio funcionamiento, se abordan
conceptos básicos, tales como repositorio o módulo, para luego
pasar inmediatamente a su uso. Se
describirán las principales funciones que éste realiza, enfocado desde la
perspectiva de un usuario que desea comenzar a utilizar rápidamente CVS para
su proyecto. Como será posible
apreciar, esta herramienta es muy útil y sencilla de utilizar.
Para
quienes se interesen en el tema, se anexará un ejemplo de uso en Aragorn,
además de información que profundiza en algunas opciones de CVS, así como
referencias a sitios que tratan características más avanzadas del software.
1.- Introducción
Es común que al trabajar con un proyecto de
software o programación con cierto grado de complejidad, surja la necesidad
de controlar de forma ordenada su crecimiento y evolución.
Se hace necesario mantener un historial y disponer de algún mecanismo
que permita volver a alguna versión anterior de un archivo si un cambio
reciente hizo que las cosas dejaran de funcionar, o comparar versiones
anteriores con la actual para detectar qué parte es la que está produciendo
el problema.
Los sistemas de control de versiones (VC) buscan resolver estos
inconvenientes, junto con agregar funcionalidad adicional que facilite la
tarea para el o los desarrolladores involucrados, entre las que destacan la
libre modificación de un proyecto sin miedo a destruir trabajo anterior,
mediante la creación automática de copias de trabajo del proyecto original,
o almacenar sólo las modificaciones efectuadas recientemente sobre los
archivos, las que serán enviadas al repositorio con un nuevo número de
revisión.
En particular, se tratará el caso de CVS (Concurrent Versions
System), un sistema de control de versiones de GNU disponible para la
mayoría de las plataformas (Unix, Linux, Windows, etc.).
Su funcionamiento es muy simple: el desarrollador se conecta con el
servidor CVS y le pide la última versión disponible del proyecto, con lo
cual puede ver qué cambios se han realizado respecto a su versión local y
los conflictos que pudiera ocasionar el código que ha estado realizando con
el que ya está disponible en el servidor. En caso de que no sea
problemático, se modifican los ficheros locales respetando los cambios
efectuados por el desarrollador.
El servidor CVS se encarga de manejar el histórico de lo que
ocurre, mantener un registro de los cambios realizados a cada fichero y de
servirlos según las necesidades del desarrollador. Además, gestiona diversas
utilidades para controlar en qué ficheros se está trabajando, notificar a
los autores de los ficheros de los cambios, etc.
El cliente CVS se encarga de
obtener las últimas versiones disponibles (o las que necesite), de
confrontarlas con las copias locales, y de añadir el código del
desarrollador al proyecto.
Inicio
2.- Conceptos
Básicos
2.1.-
Revisión: Un cambio aplicado y registrado en el historial de un
fichero o conjunto de ficheros. Una
revisión es una copia instantánea de un proyecto que cambia constantemente.
2.2.- Repositorio:
La copia maestra en la que CVS guarda el historial de revisiones al completo
efectuadas en un proyecto. Cada
proyecto tiene exactamente un repositorio.
2.3.- 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.
2.4.- Copia de trabajo: Copia del proyecto que se encuentra en el repositorio y nos permite
realizar cambios sobre éste. Puede
haber muchas copias de trabajo de un proyecto dado. Por regla general, cada desarrollador tiene su propia copia
de trabajo.
2.5.- Obtener una copia (“check out”): Solicitar una copia de trabajo al repositorio.
2.6.- Enviar (“commit”):
Enviar cambios de su copia local al repositorio central.
también conocido como check-in.
2.7.-
Informe de Cambios: Un comentario que se adjunta a una revisión cuando
ésta se envía, describiendo los cambios realizados. Otros pueden leer los informes de cambios para obtener un
resumen de lo que ha estado sucediendo en un proyecto.
2.8.- Actualizar
(“update”): Incorporar a la copia
de trabajo los cambios que otros han hecho y están presentes en el
repositorio, y comprobar que la copia de trabajo tiene algún cambio que no ha enviado todavía.
Inicio
3.-
Creación de un Repositorio
La ubicación del repositorio esta
definida por la variable de entorno CVSROOT y se define de la siguiente
manera:
$export CVSROOT=/home/alm99/login/repositorio
Una vez definida esta variable la sintaxis para crear
el repositorio es:
$cvs init
Es posible crear el repositorio sin definir la variable de entorno,
para este caso debemos usar la opción global –d (de “directorio”),
seguido por la ruta que apunta al repositorio, por ejemplo:
$cvs –d /home/alm99/login/repositorio init
Ambas formas inicializan el repositorio, creando
archivos generales de administración para el correcto funcionamiento de él
mismo.
4.- Acceder a un
Repositorio
Con CVS puede trabajarse en forma local (repositorio y
copia de trabajo en el mismo sistema) o
remota (el repositorio esta en un sistema servidor y la copia local en un
cliente del primero). Estos dos
casos se ilustran a continuación:
4.1.- En
el sistema local, como es el caso de /home/alm99/login/repositorio por
ejemplo:
$cvs –d /home/alm99/login/repositorio comando
o también análogamente una vez definida la variable
de entorno:
$cvs comando
4.2.- En
forma remota, usando ssh (OpenSSH)
Para
que CVS use este modo de acceso se deben usar estas variables de entorno:
$export
CVSROOT=:ext:usuario@aragorn.elo.utfsm.cl:/home/alm99/login/repositorio
$export CVS_RSH=ssh
donde usuario es el nombre de usuario que tiene acceso
al repositorio, aragorn.elo.utfsm.cl, es el nombre del servidor donde se aloja
el repositorio, /home/alm99/login/repositorio
es el directorio del servidor en el que está el repositorio.
Se deberá tener en cuenta que, usando esta técnica, tendremos que
autentificarnos (es decir, suministrar nuestra contraseña) cada vez que
ejecutemos alguna orden de CVS.
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.
Inicio
5.- Comenzar un
proyecto nuevo:
Introducir un proyecto nuevo al repositorio CVS se denomina importar.
Por lo tanto se usa cvs import.
Primero nos debemos ubicar en el directorio raíz del proyecto.
Por ejemplo:
$
cd proyecto1
$
cvs import –m “importación de la tarea a CVS” proyecto1 login start
La opción –m (mensaje) sirve para especificar un breve informe que
describe la importación (su inclusión es obligatoria).
Éste será el primer informe de cambios que afecta al proyecto en todo
su conjunto; cada envío realizado en el futuro tendrá su propio informe de
cambios. El siguiente argumento es el nombre del proyecto, con el cual se
obtendrán copias del repositorio (el nombre elegido no tiene por qué ser
igual al del directorio actual). Luego
se utiliza un nombre de usuario (login) y start, que son información
de registro adicional para CVS. Con
la secuencia anterior se importará el contenido del proyecto proyecto1 con
todos sus archivos y subdirectorios, quedando disponibles en el repositorio
como versión original sobre la cual se pueden sacar todas las copias que se
deseen para trabajar sobre ellas.
El servidor de CVS se encarga de mantener los ficheros que conforman
nuestro proyecto de tal forma que se mantienen los cambios realizados hasta el
momento. En la raíz del servidor
se encuentran los módulos que están disponibles, normalmente cada
módulo corresponde a un directorio en el raíz. Los directorios que cuelgan
de un directorio del raíz se consideran submódulos, es decir, la
estructura es así:
/Raíz_CVS
|
|---/Módulo_1
| |
| |---/Submódulo_1 del Módulo_1
| |---/Submódulo_2 del Módulo_1
|
|---/Módulo_2
|---/CVSROOT
Los ficheros que el servidor almacena
son del tipo fichero.ext,v.
En estos ficheros se encuentran los originales, los cambios realizados en las
versiones anteriores y más información.
El directorio CVSROOT contiene la configuración y ficheros de
información del servidor CVS.
Al llegar a este punto, se puede pensar que, puesto
que se ha importado el proyecto, puede
empezarse a trabajar en él inmediatamente.
Éste sin embargo, no es el caso: el árbol de directorio actual no es
todavía una copia de trabajo de CVS. Fue
el origen para el comando de importación, pero no por eso se ha convertido
por arte de magia en una copia de trabajo de CVS: para obtener una copia en la
que se pueda trabajar, se deberá tomar del repositorio.
Y éste será el paso siguiente.
Inicio
6.-
Obtener una copia de trabajo
El comando para obtener un
proyecto es checkout. Sólo
debemos ubicarnos en el directorio donde queremos obtener la copia:
$
cd micopia
$
cvs checkout proyecto1
donde
proyecto1 es el nombre del proyecto que se copiará.
El contenido de
la copia obtenida, es exactamente el mismo que el que hemos importado
anteriormente, con el añadido de un subdirectorio llamado “CVS”.
Ahí es donde CVS guarda la información de control de versiones.
De hecho, cada directorio presente en el proyecto tiene un
subdirectorio “CVS”.
/Directorio_Local
|
|---/Módulo_1
|
|---/Submódulo_1
del Módulo_1
|
|---/CVS
|
|---/Submódulo_2
del Módulo_1
|
|---/CVS
|
|---/CVS
El hecho de que CVS guarde la información de revisiones en
subdirectorios llamados “CVS” conlleva
a que el proyecto no puede tener nunca subdirectorios propios llamados “CVS”.
El directorio “CVS” tiene los siguientes ficheros:
-
Root : contiene la ruta del repositorio.
-
Repository : contiene la ruta de un proyecto dentro
del repositorio.
-
Entries : contiene información sobre cada uno de los
ficheros que forman parte del proyecto. Cada
línea se corresponde con el fichero, y solo hay líneas para ficheros o
subdirectorios en el directorio padre inmediato.
El formato de cada línea es:
/nombre
de fichero/número de revisión/fecha de
la última modificación//
Las
líneas de directorio vienen precedidas con la letra “D”, las marcas de
fecha guardan la fecha y hora de la última actualización de los ficheros
presentes en la copia de trabajo. De
esta forma, CVS puede saber fácilmente si un fichero ha sido modificado desde
la última obtención de copia de trabajo,
actualización o envío. Si
la fecha registrada por el sistema de ficheros difiere de la fecha anotada en
el fichero CVS/Entries, CVS sabe que el fichero ha sido probablemente
modificado.
7.- Actualización
de nuestra copia local
Para actualizar nuestra copia local respecto a los
cambios del repositorio central se utiliza el comando update. El
resultado de este comando nos indicará los archivos que hayamos modificado
localmente con una M, los ficheros que se actualizan
con U, los ficheros que tienen conflictos con C
y
un ? en caso de que tengamos ficheros localmente que no
existen en el repositorio. Como
argumento se puede pasar el nombre del fichero a actualizar, de lo contrario
se actualiza todo el proyecto.
$ cvs update
Otro comando útil que permite obtener un informe más detallado de los
cambios producidos en los ficheros es diff.
Este muestra cualquier diferencia entre los ficheros de la copia local
y sus homónimos en el repositorio. Si
se usa con la opción –c muestra la información de manera más clara.
$ cvs diff –c
Inicio
8.- CVS y argumentos
implícitos
En
cada uno de los comandos de CVS explicados hasta el momento no hemos
especificado fichero alguno en la línea de comando.
Por ejemplo hemos utilizado:
$cvs
diff
en
lugar de
$cvs diff archivo
y
$cvs update
en
lugar de
$cvs update archivo
El principio que dicta esto es que si no especificamos
ningún nombre de fichero, CVS actuará sobre todos los ficheros que el
comando resulte apropiado. Esto
incluye también ficheros en subdirectorios situados por debajo del directorio
actual; CVS desciende automáticamente desde el directorio actual hasta cada
subdirectorio en el árbol.
Inicio
9.- Enviar cambios
al repositorio
El comando commit envía al repositorio las
modificaciones que hemos estado realizando en nuestra copia local.
Si no se indica ningún fichero, el comando enviará todos los cambios
al repositorio.
$cvs commit -m "mensaje que resume el
cambio"
Es necesario agregar un mensaje que indicará resumidamente los cambios
que se han introducido respecto a la versión en que se trabajaba.
Hay que recalcar que al
enviar un fichero al repositorio el proyecto original no se ve afectado, sino
que se agrega una nueva revisión, por ejemplo si se trabajaba en la 1.2, los
cambios quedarán en la 1.3. Puesto
que seguramente sólo se ha modificado sólo parte del total de ficheros, al
enviar los cambios al repositorio sólo aquellos serán incorporados con un
nuevo número de revisión; el resto conservará el que tenía, en vista que
no se han modificado. Así,
cuando un cliente solicita una copia del proyecto obtiene la última revisión
de cada fichero contenido en el repositorio, es decir, no todos los ficheros
tienen por qué tener el mismo número de revisión.
10.- Detección y
resolución de conflictos
Cuando dos
desarrolladores están trabajando sobre el mismo archivo es posible que en
algún momento las modificaciones que realiza cada uno de ellos coincida.
Entonces, cuando el segundo actualice el archivo, CVS le devolverá una línea
de error mostrando lo que tiene la versión local y lo que tiene la versión
del repositorio. Además señala
que estos cambios deben ser fusionados. Al hacer una actualización (update),
CVS fusionará los cambios en el fichero.
La manera de resolver el conflicto es simplemente editando el fichero
de forma que tenga el texto que resulte apropiado, eliminando de paso los
marcadores de conflicto que agregó CVS.
Entonces recién se procede a enviarlo al repositorio.
Inicio
11.- Averiguar
quién hizo qué (leyendo informes de cambios)
Suponiendo que el proyecto a pasado por varios
cambios y queremos saber que archivos han sido modificados, no es necesario
examinar con detalle cada fichero de diferencias.
Examinar los informes de cambios sería lo ideal, y se puede realizar
con el comando log:
$cvs
log
(páginas y páginas de salida omitida)
La
salida del comando tiene a ser bastante detalla.
12.- Examinar y
deshacer cambios
Supongamos que, mientras estamos leyendo los informes
de cambios, el usuario “login1”, se percata que “login2” hizo el
cambio mas reciente a “archivo”. Y
nos preguntamos que cambios hizo “login2” exactamente, o dicho de otra
forma ¿Cuál es la diferencia entre mi revisión (1.2) de “archivo y la
revisión de “login2” que vino a continuación (1.3)?
La forma de averiguarlo es utilizar el comando diff, pero esta vez comparando las 2 últimas
revisiones utilizando la opción de comando –r para especificar ambos
números:
$cvs diff –c –r 1.2 –r 1.3 archivo
Este
comando entrega como salida las líneas de código en que ambos archivos
difieren.
Inicio
13.- Método para
deshacer cosas
Siguiendo con el supuesto anterior, cuando el usuario
login1 ve los cambios realizados, decide que le gusta mas su forma de hacer
las cosas, así que decide deshacerlo , esto es ir a una revisión mas atrás
(1.2). La pregunta es ¿cómo se
pude obtener el contenido de la revisión 1.2 y ponerlo en la 1.4 ?
Existen
2 posibles escenarios: cuando el cambio es relativamente sencillo, login1
puede seguramente limitarse a editar el fichero a mano para hacerlo idéntico
a la revisión 1.2 y entonces enviarlo al repositorio. Sin embargo, si los cambios son más complejos (como suele
ocurrir en un proyecto real), intentar recrear a mano la revisión antigua
será irremediablemente algo donde se producirán errores. Por tanto, vamos a realizar que login1 use CVS para obtener y
reenviar el contenido de la
antigua versión.
La forma rápida y vistosa de deshacer es usando la opción –j (“de
juntar”) al comando de actualización.
Esta opción es similar a –r en el sentido de que utiliza un número
de revisión , y de que puede usar hasta dos –j a la vez.
CVS calcula la diferencia entre las dos revisiones nombradas y aplica
esta diferencia como un parche al fichero en cuestión (con lo cual, será de
vital importancia el orden en el que indique estas revisiones al comando),el
comando seria:
$cvs update –j 1.3 –j 1.2 archivo
Por
lo tanto tenemos una nueva revisión (1.4) para el fichero “archivo”.
Inicio
14.- Añadir
archivos y directorios al repositorio
Durante el
desarrollo de un proyecto es casi seguro que necesitaremos incluir más
ficheros de los que estaban previstos al comienzo del mismo. Para incluir un
fichero nuevo solamente será necesario utilizar el comando add y
el fichero a añadir al repositorio. Para añadir un nuevo directorio se sigue
el procedimiento es similar. La
diferencia está en que para el caso de un fichero hay que enviarlo al
repositorio (commit), mientras que para el directorio no.
$
cvs add nuevofichero.txt
$
cvs commit -m "adición de nuevo fichero” nuevofichero.txt
Para el caso de agregar un directorio sería:
$ mkdir new-subdir
$cvs add new-subdir
Al revisar el contenido del nuevo directorio en la
copia de trabajo, se verá que el comando add ha añadido
automáticamente un subdirectorio “CVS”.
15.- Ficheros
binarios
CVS maneja los ficheros en un formato especial y al
trabajar con archivos binarios es posible que estos pudieran ser
malinterpretado por el servidor al guardarlos (con lo que seguramente
perderíamos el fichero). Por lo
tanto, cuando se añada un fichero binario hay que decirle a CVS que desactive
tanto la expansión de palabras clave, como la conversión de finales de
línea. Esto se hace con la
opción –kb:
$cvs add –kb binario.exe
$cvs commit –m
“añadido fichero binario” binario.exe
Se debe tener en cuenta que no tiene sentido utilizar cvs diff
sobre dos revisiones de un fichero binario.
Diff utiliza un algoritmo basado en texto que sólo puede
discernir si dos ficheros binarios son distintos, pero no la forma en que
difieren.
Inicio
16.- Eliminar
ficheros
Eliminar un fichero es similar a añadir uno, con la
salvedad de que se debe hacer un paso adicional: eliminar primero el fichero
de la copia de trabajo.
$rm nuevofichero.tx
$
cvs remove nuevofichero.txt
$
cvs commit –m “eliminando archivo” nuevofichero.txt
Se resalta el hecho de hacer referencia a nuevofichero.txt de
forma explícita (segundo y tercer comandos) a pesar de que ya no existe en la
copia de trabajo.
17.- CVS y los ficheros
eliminados
CVS se encarga de mantener un histórico y todas las
versiones de los arhivos que hay en los proyectos.
Si esto es cierto no se pueden borrar los ficheros, pues aunque no sean
necesarios en las versiones actuales del proyecto, sí que lo fueron en etapas
anteriores.
En realidad, CVS no borra ningún fichero del
repositorio; simplemente lo mueve a un directorio llamado Attic
y
lo marca como “muerto” estando disponible en caso de desear “revivirlo”.
Inicio
18.- Formas
abreviadas
La
mayor parte de los comandos CVS tienen una forma abreviada, para hacer más
fácil el escribirlos. Se puede
obtener una lista de todas las formas abreviadas ejecutando el comando cvs
–help-synonyms.
Las más usadas son las siguientes:
¨ checkout=co
¨ update=up
¨
commit=ci
19.- Marcar con
etiquetas
Uno de los
inconvenientes de trabajar con CVS es que siempre se manejan los ficheros con
sus versiones, y mantener una lista de versiones con todos los archivos puede
resultar muy molesto en proyectos no muy grandes.
Para evitar esto existe el comando tag etiqueta que nos
permite enlazar diferentes versiones con un nombre simbólico.
Por ejemplo:
$ cvs tag vers_22-10-2003
20.- Liberando una
versión
A lo largo del
desarrollo surgen versiones que son estables y pueden ser distribuidas.
Para evitar a los posibles usuarios el uso de CVS, se realiza una copia
exacta de la versión etiquetada mediante el comando export -t etiqueta -d
ruta_destino módulo, la cual no contendrá los directorios CVS
y
será distribuíble si se empaqueta con tar y gzip, por
ejemplo.
$ cvs -d /home/cvs/ export -t v0.5 -d
/home/royaq/cvsdoc-0.5 cvs-doc
Inicio
CONCLUSIÓN
Como primera instancia se puede concluir que CVS es
una herramienta poderosa y sencilla para el uso de grandes proyectos, en donde
interactúan una gran cantidad de usuarios.
Al finalizar este trabajo se puede decir que se ha
adquirido los conceptos fundamentales acerca del trabajo con CVS, se han
aprendido aspectos de instalación, configuración, creación y manipulación
de sistemas de control de versiones. Es
importante recordar que este pequeño proyecto cubre los aspectos
fundamentales de CVS. Para aquellos usuarios que quieran profundizar más
en el tema, deben dirigirse a las referencias.
REFERENCIAS
La
bibliografía del trabajo esta basado principalmente en sitios web:
-
http://gsyc.escet.urjc.es/actividades/linuxprog/prog/node3.html
-
http://qref.sourceforge.net/Debian/reference/ch-vcs.es.html
-
http://www.loria.fr/cgi-bin/molli/wilma.cgi/doc
-
http://cvsbook.red-bean.com
Anexo
A: Instalación y Configuración
de CVS
Instalación de CVS
Para
la instalación del CVS, podemos acceder vía ftp a ftp://ftp.cvshome.org/pub/
dónde podemos encontrar la ultima versión del cvs que ha sido desarrollada o
bien instalarlo vía paquete deb o rpm, para los debianeros con un apt-get
install cvs, nos servirá, para los que decidan instalarlo desde las fuentes
sería de la siguiente manera:
# tar xzvf cvs-1.xx.tar.gz
# cd cvs-1.xx
# ./configure
# make
# make install
Con esto ya tendremos instalados
el CVS en nuestro sistema, de forma que quedaría definir el repositorio al
que posteriormente queramos conectarnos, bien sea un repositorio local en caso
de hacer servidor CVS o bien de forma remota en caso de querer acceder como
cliente a un servidor CVS definido en la variable $CVSROOT.
Configuración
de cvs
-
Ficheros de configuración:
~/.cvsrc,
~/.cvswrappers
-
Información sobre la configuración
~/.cvsrc:
es
el principal fichero de configuración de cvs. Este fichero es utilizado por
los usuarios para especificar las opciones por defecto de los diferentes
comandos de cvs, por ejemplo, para hacer que todos los comandos cvs diff se
ejecuten con -u, el usuario puede añadir diff -u en su fichero .cvsrc.
~/.cvswrappers:
especifica
los envoltorios (wrappers) que se van a usar además de los indicados en el
fichero CVSROOT/cvswrappers del repositorio.
Inicio
Anexo
B: Guía rápida de comandos
·
cvs -m “comentario”' import [proyecto] [usuario] start
Inicia
un proyecto en un repositorio. Basta
con colocarse dentro del directorio con los ficheros fuente y ejecutar este
comando.
·
cvs checkout [proyecto]
adquiere
del repositorio la última versión de [proyecto].
·
cvs checkout -r ``Nombre de la Release'' [proyecto]
adquiriere
del repositorio un snapshot del [proyecto].
Los
siguientes comandos deben ejecutarse dentro del directorio donde previamente
se bajó la copia del proyecto.
·
cvs commit
sube
al repositorio las modificaciones hechas al proyecto.
·
cvs update
Actualiza
el proyecto, bajando todas las modificaciones hechas en el repositorio y
volcándolas en la copia local.
·
cvs status
Devuelve
información relativa a cada archivo que conforme el proyecto, datos como
número de revisión y fecha de última modificación.
·
cvs log
Muestra
cada uno de los mensajes escritos en el log, cada vez que se hizo un commit.
·
cvs diff -c -r [numero de revisión] [archivo]
Muestra
las diferencias que existen entre la revisión [numero de revisión] respecto
de un [archivo] en particular. En
caso de no usar [archivo] lo aplica a todos los archivos.
·
cvs update -j [número de revisión] -j [número de revisión] [archivo]
Sirve
para volver al [número de revisión]. Genera automáticamente un patch y lo
aplica sobre el directorio en donde se encuentran las fuentes.
En caso de no usar [archivo] lo aplica a todos los archivos.
·
cvs -q tag ``Nombre de la Release''
Sirve
para marcar un snapshot de nuestro proyecto con un nombre dado.
·
mkdir [dir]; cvs add [dir]
Agrega
un directorio al repositorio.
·
cvs add [Archivo_nuevo]
Agrega
un archivo nuevo al repositorio.
·
rm -f [Archivo]; cvs remove [Archivo]
Elimina
un archivo del repositorio.
·
rmdir [dir]; cvs remove [dir]
Elimina
un directorio del repositorio.
Inicio
Anexo
C: Ejemplo de uso
La siguiente secuencia
pretende ser una ayuda para trabajar sobre un conjunto de archivos que serán
modificados al interior de una cuenta de usuario en Aragorn (por ej. una tarea
del programación), sobre la que se tiene ya una estructura inicial definida,
y se desea introducir modificaciones sin afectar esta versión original.
Acceder
al repositorio:
Esto se hace con la opción –d.
Por ejemplo, si el repositorio se encuentra Aragorn, en la ruta
/home/alm99/royaq/cvs, donde royaq es el nombre de usuario y cvs el directorio
que contendrá el repositorio, la forma de acceder a él estando loggeado
en la cuenta es:
$ cvs –d /home/alm99/royaq/cvs comando
Si
sólo se está utilizando un repositorio a la vez, una forma de no tener que
estar constantemente tecleando toda la ruta es definiendo la variable de
entorno CVSROOT, tal como sigue:
$
export CVSROOT=/home/alm99/royaq/cvs
con
lo cual, de ahora en adelante simplemente se tecleará:
$
cvs comando
Creación del repositorio:
Estando
en el directorio en el que se ubicará el repositorio éste debe ser
inicializado (cvs init), con lo que se crea un directorio llamado
CVSROOT que contendrá los archivos de configuración del repositorio.
En este ejemplo, dentro del directorio cvs (que previamente será
creado y alojará el repositorio) teclear:
$
cvs init
con
lo cual ya se está en condiciones de comenzar un proyecto.
Notar que se crea un directorio CVSROOT que contiene ficheros de
configuración.
Comenzar
un nuevo proyecto:
Introducir un proyecto nuevo al repositorio CVS se denomina importar.
Por lo tanto se usa cvs import. Primero nos debemos ubicar en el directorio raíz del
proyecto. Por ejemplo:
$ cd
ejemplocvs
$
cvs import –m “importación de la tarea a CVS” ejemplocvs royaq start
N
ejemplocvs/texto.txt
No conflicts created by this import
La
opción –m (mensaje) sirve para especificar un breve informe que describe la
importación (su inclusión es obligatoria).
El siguiente argumento es el nombre del proyecto, con el cual se
obtendrán copias del repositorio (el nombre elegido no tiene por qué ser
igual al del directorio actual). Luego
se utiliza un nombre de usuario y start.
Con la secuencia anterior se importará el contenido del proyecto
ejemplocvs con todos sus archivos y subdirectorios, quedando disponibles en el
repositorio como versión original sobre al cual se pueden sacar todas las
copias que se deseen, para trabajar sobre ellas. En este ejemplo el directorio ejemplocvs sólo contiene un
archivo (texto.txt), el cual es importado al repositorio. La N que lo precede indica que es un nuevo fichero.
Además se indica que no hubieron conflictos durante la importación.
Obtener
una copia de trabajo
El siguiente paso es obtener la copia del proyecto sobre la que haremos
todos los cambios deseados, sin afectar la versión original. Para esto se usa
el comando checkout. Sólo
debemos ubicarnos en el directorio donde queremos obtener la copia
$
cd micopia
$
cvs checkout ejemplocvs
cvs
checkout: Updating ejemplocvs
U
ejemplocvs/texto.txt
donde ejemplocvs es el nombre del proyecto que se copiará. Una U precede a cada fichero que ha sido copiado.
Enviar cambios al
repositorio
El comando commit permite realizar esto.
Si, por ejemplo, dos personas están trabajando sobre el mismo fichero,
del cual los dos poseen una copia y uno de ellos ha introducido una
modificación a un archivo y desea enviarla al repositorio, sólo debe
teclear:
$cvs commit -m "incluí una nueva función"
cvs commit: Examining .
Checking in texto.txt;
/home/alm99/royaq/cvs/ejemplocvs/texto.txt,v <-- texto.txt
new revision: 1.2; previous revision: 1.1
done
Con esto se envía una nueva revisión al repositorio (la 1.2) que
quedará disponible para cualquier persona que desee una copia de repositorio.
Nuevamente se debe incluir un mensaje que describa brevemente la
modificación introducida. La
salida indica que se ha enviado texto.txt (el fichero modificado); el resto se
explica por sí solo.
Actualizar
nuestra copia local
Se puede actualizar la copia local con el comando update, para
asegurarnos que nuestra copia corresponda a la última revisión disponible en
el repositorio (por si alguien más ha hecho cambios sobre el fichero del
ejemplo).
$
cvs update
cvs
update: Updating
M
texto.txt .
Esto realiza una actualización de todo el proyecto.
En la lista devuelta como salida del comando, los archivos modificados
localmente estarán precedidos de una M, los que se actualizan con una U y los
que tienen conflictos con una C. En
este ejempl, a la copia local se le ha insertado una nueva línea, de ahí la
M que precede a texto.txt.
También se puede solicitar un informe detallado de los cambios con el
comando diff:
$
cvs diff
retrieving
revision 1.2
diff
-r1.2 texto.txt
4a5
>
//Agregué esta línea
El comando diff compara los ficheros que puedan haberse modificado en
la copia de trabajo con sus homónimos en el repositorio, mostrando a
continuación cualquier posible diferencia.
El ejemplo indica que en el fichero texto.txt se ha agregado una nueva
línea en la línea 4 (la que ahora pasa a ser la 5), mostrando
explícitamente cuál es el cambio (el caracter > indica que esta línea se
encuentra presente en la nueva versión, pero no en la antigua).
El ejemplo anterior presenta un ejemplo sólo con los comandos
principales de CVS, son los que con mayor frecuencia se utilizan.
Para profundizar más, ver la guía rápida de comandos o consultar las
referencias.