Universidad Técnica Federico Santa María Departamento de Electrónica Programación de Sistemas Sistema de Control de Versiones CVS Profesor: Agustín González Integrantes: Daniel Vergara C. Rodrigo Yañez Q.
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.
2.- Conceptos Básicos Antes de comenzar, definiremos la terminología básica de CVS: 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. 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. 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. 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
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. 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. 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. 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
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.
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. 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
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 está basada principalmente en sitios web: 1.- http://www.cvshome.org : Sitio oficial del proyecto. 2.- http://cvsbook.red-bean.com: Excelente documentación. 3.- http://www.loria.fr/cgi-bin/molli/wilma.cgi/doc 4.- http://gsyc.escet.urjc.es/actividades/linuxprog/prog/node3.html 5.- http://qref.sourceforge.net/debian/reference/ch-vcs.es.html 6.- http://www.wincvs.org
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.
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.
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.