Gentoo Logo

Tutorial de CVS de Gentoo Linux

Contenido:

1.  Introducción

Esquema del tutorial

Este tutorial tiene dos partes. La primera de ellas muestra cómo usar CVS como un no-desarrollador, por ejemplo, para obtener las fuentes desde el CVS y mantenerlas actualizadas. La segunda nos introduce a cómo utilizar CVS como un desarrollador, modificando, agregando y borrando archivos, además de otras tareas relacionadas al desarrollador. Si eres nuevo en CVS, te recomiendo que empieces por la primera sección y luego pasar a la segunda; si tienes alguna experiencia básica sobre CVS pero por primera vez utilizarás CVS como desarrollador, encontrarás todo lo que necesitas en la segunda sección, pero es factible que tengas que pasar por la primera parte para un repaso.

¿Qué es CVS y qué es lo que hace?

CVS es un sistema cliente/servidor que permite a los desarrolladores almacenar sus proyectos en un lugar central, llamado repositorio. Mediante el uso de herramientas que se ejecutan del lado del cliente, los desarrolladores pueden realizar cambios en los contenidos del repositorio. Mientras tanto, el repositorio cvs sigue cada cambio realizado a cada archivo, y genera un completo historial de la evolución del proyecto. Los desarrolladores pueden pedir versiones anteriores de un archivo fuente en particular, observar los comentarios acerca de los cambios y realizar otras tareas bastante útiles como sea necesario.

El rol del CVS

Muchos proyectos de software de código abierto (open source software) tienen sus propios servidores CVS, los cuales son utilizados por los desarrolladores del proyecto como un repositorio central para todo su trabajo. Por lo general, los desarrolladores realizan pequeñas mejoras al código que se encuentra en el repositorio CVS diariamente; y estos desarrolladores, por lo general, se encuentran dispersos en todo el mundo, sin embargo CVS provee el mecanismo necesario para unificar su proyecto en un "todo" cohesivo y centralizado. CVS crea el "pegamento organizador" que permite a estos desarrolladores a realizar mejoras al código sin pisarse los unos con los otros, con la consecuente pérdida de datos importantes o perdiendo actualizaciones críticas e importantes que otro desarrollador pudo haber realizado a algún archivo en particular.

CVS -- las últimas fuentes del desarrollador

Cuando los desarrolladores están listos, ellos generarán un archivo .tar.gz en donde se encuentra el trabajo realizado en CVS, este archivo será el nuevo paquete oficial de su software. Sin embargo, algunas veces la última versión del software no es lo suficientemente reciente, y esto es debido varias razones propias de cada proyecto. En la primer sección de este tutorial, mostraré como usar CVS para este propósito -- obtener la última versión de las fuentes de los desarrolladores para tu uso personal.

Instalando CVS

Para instalar CVS tan solo ejecute emerge cvs:

Listado de Código 1.1: Instalando CVS

# emerge cvs

El CVSROOT

Antes de comenzar, existen ciertas cosas básicas y elementales del CVS que hay que saber. La primera de ellas, es que para poder conectarnos al repositorio de CVS, primero debes de conocer la ruta de "CVSROOT". El CVSROOT es una cadena de caracteres (string), que como la URL, le indica la ubicación del repositorio al comando cvs y como nos gustaría conectarnos a el. Solo para hacer las cosas más interesantes, CVS tiene varios formatos para la variable CVSROOT, los cuales dependen la ubicación del repositorio CVS (local o pública) y que método usarás para conectarte contra él. Aquí van algunos ejemplos con una par de explicaciones del CVSROOT.

CVSROOT local

Listado de Código 1.2: Configurando CVSROOT

CVSROOT=/var/cvsroot

Este es un ejemplo de una ruta local para el CVSROOT; un CVROOT como este se usa para conectarse contra un repositorio local que existe en /var/cvsroot; o tal vez si el repositorio se encuentra montado vía NFS en /var/cvsroot.

Un CVSROOT remoto con contraseña

Listado de Código 1.3: Configurando un CVSROOT con contraseña

CVSROOT=:pserver:cvs@foo.bar.com:/var/cvsroot

Este es un ejemplo de un CVSROOT de un repositorio remoto que existe en el host foo.bar.com y se encuentra en el directorio /var/cvsroot de esa máquina. El prefijo ":pserver:" sirve para comunicar a nuestro cliente a que se conecte a ésta máquina remota usando el protocolo del servidor CVS para contraseñas, un protocolo que está empotrado en CVS. Por lo general, los repositorios CVS públicos usan dicho protocolo para permitir acceso anónimo.

Un CVSROOT remoto con rsh/ssh

Listado de Código 1.4: CVSROOT con RSH/SSH

CVSROOT=drobbins@foo.bar.com:/data/cvs

Este es un ejemplo de un CVSROOT que usa el protocolo RSH o SSH; en este ejemplo, el servidor CVS tratará de acceder al repositorio en foo.bar.com usando la cuenta drobbins. Si la variable de ambiente CVS_RSH se encuentra configurado con el valor de "ssh", entonces nuestro cliente cvs tratará de utilizar ssh para conectarse; caso contrario, rsh será usado. El método de acceso con el uso de ssh es popular entre aquellos que tienen en cuenta la seguridad; sin embargo, ninguno de los dos métodos nos provee una manera para que usuarios anónimos puedan obtener las fuentes. Para utilizar este método, tienes que tener una cuenta de usuario en foo.bar.com.

Un par de cosas más ...

Además del CVSROOT, también necesitarás saber el nombre del módulo (colección de fuentes) que querrás obtener, mediante el uso del check-out, como así también una contraseña para usuarios anónimos, la cual necesitarás para poder acceder al servidor. A diferencia del ftp anónimo, no existe un formato estándar para una contraseña anónima, así que necesitarás obtener una del sitio de los desarrolladores o de los desarrolladores mismos. Una vez que tienes toda esta información, estás listo para comenzar.

Interactuando con CVS, parte 1

La obtención de las fuentes es un proceso de dos etapas. primero, debemos autenticarnos contra el servidor de contraseñas. Luego, obtenemos las fuentes mediante el comando checkout. Aquí se encuentra un ejemplo con un par de comandos para la obtención de la última versión de Samba, un proyecto de integración UNIX/WINDOWS muy popular en el entorno UNIX/WINDOWS:

Listado de Código 1.5: Configurando a CVSROOT

# export CVSROOT=:pserver:cvs@pserver.samba.org:/cvsroot

El primer comando configura la variable de ambiente CVSROOT. Si no configuras esta variable, los siguientes dos comandos requerirán una opción adicional, seguido del comando cvs la cual es -d :pserver:cvs@pserver.samba.org:/cvsroot . La exportación de CVSROOT nos ahorra escribir un poco.

Interactuando con CVS, parte 2

Aquí se encuentran los comandos necesarios para obtener una copia actual de las fuentes. Si quieres puedes saltarte esta sección hasta la siguiente tabla, leer las explicaciones y luego volver aquí:

Listado de Código 1.6: Checking out sources

# cvs login
(Autenticándonos en cvs@pserver.samba.org)
CVS password: (enter password here)

# cvs -z5 co samba
U samba/COPYING
U samba/Manifest
U samba/README
U samba/Read-Manifest-Now
U samba/Roadmap
U samba/WHATSNEW.txt
(esto es solamente una parte de la salida de cvs co)

Interactuando con CVS -- la explicación

El primer comando cvs de arriba nos autentica en el pserver, y el segundo le dice a nuestro cliente CVS a que realice un check-out ("co") del módulo de samba usando una compresión gzip de nivel 5 ("-z5") para acelerar la transferencia a través de un enlace lento. Por cada nuevo archivo que es creado localmente, cvs imprime en la pantalla un "U [ruta]", indicando que este archivo en particular ha sido actualizado en disco.

Checkout completado

Una vez que el comando de checkout ha sido completado, verás el directorio "samba" en tu directorio actual, el cual contiene las fuentes. También te darás cuenta que todos los directorios tienen un directorio llamado "CVS" -- CVS almacena cierta información dentro de esos directorios, los mismos pueden ser ignorados sin cuidado alguno. Desde este punto en adelante, no es necesario preocuparse de tener la variable CVSROOT configurada, ni tampoco será necesario especificarlo en la línea de comandos, ya que el mismo ahora se encuentra dentro de todos esos directorios "CVS". Recuerda -- solamente necesitas configurar CVSROOT para la autenticación inicial y el checkout correspondiente.

Actualizando las fuentes

Bueno, ahí lo tienes -- ¡fuentes frescas! Ahora que tienes las fuentes, puedes compilarlas, instalarlas, darles una miradita, o hacer lo que quieras con ellas.

De vez en cuando, querrás tener tu directorio sincronizado con el directorio del CVS. Para hacer esto, no necesitas autenticarte al pserver otra vez; la información pertinente también está en los directorios "CVS". Primero, debes de entrar al directorio que obtuviste, en este caso samba, y luego escribir:

Listado de Código 1.7: Actualizando las fuentes

# cvs update -dP

Viendo en detalle el "cvs update", parte 1

Si existen nuevos archivos, el cvs los obtendrá y dará por salida a líneas del tipo "U [ruta]" por cada archivo. Además, si has compilado las fuentes, lo más probable es que veas muchas líneas del tipo "? [ruta]"; cvs se da cuenta que dichos archivos no se encuentran en el repositorio. (estos archivos son generados en la compilación y son llamados archivos objetos)

Viendo en detalle a "cvs update", parte 2

"-d" le dice al comando cvs a que cree cualquier directorio que haya sido agregado al repositorio (esto no es la opción por defecto), y "-P" le dice al cvs a que remueva/borre cualquier directorio vacío de tu copia local de las fuentes. "-P" es una buena idea, ya que cvs tiene la tendencia de recolectar un montón de directorios vacíos a través del tiempo. (que alguna vez fueron usados, pero han sido abandonados).

Cuando se trata de simplemente obtener las últimas fuentes, eso es todo lo que necesitas saber. Ahora, nos adentraremos un poco más para saber como interactuar con CVS como si fuéramos un desarrollador.

2.  CVS para desarrolladores

Modificando archivos

Como desarrollador, necesitarás modificar los archivos en CVS. Para hacer esto, simplemente realiza los cambios pertinentes en tu copia local del repositorio. Estos cambios que tu haces a las fuentes no son aplicadas al repositorio remoto a menos que explícitamente se le diga a cvs a que realice un "commit" de tus cambios. Cuando hayas probado y evaluado tus cambios satisfactoriamente, y estés listo para aplicar dichos cambios al repositorio local, sigue este proceso de dos pasos. Primero, actualiza ("update") tus fuentes escribiendo lo siguiente en tu directorio principal de las fuentes:

Listado de Código 2.1: Actualizando las fuentes y directorios

# cvs update -dP

Fusión (merge) de los cambios de otros con CVS

Como hemos visto anteriormente, "cvs update" actualizará tus fuentes a la versión actual del repositorio -- pero ¿qué ocurre con los cambios que tu has hecho? No te preocupes, ellos no han sido ni pisados ni descartados. Si otro desarrollador ha realizado cambios a algún archivo que tu no has tocado, entonces tu copia local será actualizado de manera que esté sincronizado con la versión del repositorio.

Y, si has modificado las líneas 1-10 de tu copia local, y otro desarrollador ha borrado las líneas 40-50, agregado 12 nuevas líneas al final del archivo, modificado las líneas 30-40 y luego haya realizado un commit de sus cambios al repositorio antes que tu, cvs inteligentemente, tratará de realizar la fusión de dichos cambios en tu copia local, de manera que ninguno de tus cambios se pierdan. Esto permite que dos o más desarrolladores trabajen sobre diferentes partes de un mismo archivo al mismo tiempo.

El proceso de fusión (Merging) no es perfecto

Sin embargo, si dos o más desarrolladores han realizado cambios a la misma parte del mismo archivo, las cosas se tornan un poquito más complicadas. Si esto sucede, entonces cvs te comunicará que ha ocurrido un conflicto. Ningún cambio será perdido, pero se requiere de un poco de intervención manual, ya que cvs ahora necesita que tú le digas como realizar la fusión de los cambios conflictivos.

El "commit"

Observaremos exactamente como los conflictos pueden ser resueltos en un momento, pero por ahora, asumamos que no hay conflicto alguno cuando has tipeado "cvs updatee -dP" -- y generalmente dichos conflictos no ocurren. Sin conflictos, tu copia local de las fuentes están actualizadas, y estás listo para realizar el "commit" de tus cambios al repositorio. Para hacerlo, debes tipear lo siguiente en el directorio principal correspondiente:

Listado de Código 2.2: Realizando el 'commit' de los cambios

# cvs commit

Lo que hace el "commit"

"cvs commit" no aplica solamente tus cambios al repositorio. Antes de aplicar los cambios al repositorio remoto, cvs lanzará tu editor por defecto para que puedas tipear una descripción de tus modificaciones. Una vez que tus comentarios hayan sido escritos y guardados, en el momento en que salgas del editor, tus cambios y tus comentarios serán aplicados al repositorio remoto, y estarán a disposición los desarrolladores de tú equipo.

Observando la bitácora (log)

Es realmente fácil de ver el historial completo de un archivo particular, como así también los comentarios hechos por los desarrolladores (incluyéndote a ti) en el momento de realizar el 'commit'. Para poder observar esta información, tienes que escribir:

Listado de Código 2.3: Mirar la información del log

# cvs log myfile.c

El comando "cvs log" es recursivo, de manera que si quieres ver el log para un árbol de directorios completo, simplemente debes de tipear el directorio en cuestión:

Listado de Código 2.4: Observar la información de la bitácora (log) con un paginador

# cvs log | less

Opciones para commit

Si quieres utilizar otro editor del que cvs lanza por defecto cuando ejecutas "cvs commit", entonces simplemente tienes que configurar la variable de entorno llamada EDITOR al nombre del ejecutable del editor que quieras usar. Una buena idea sería incluir dicha configuración en el archivo /.bashrc:

Listado de Código 2.5: Estableciendo tu editor

export EDITOR=jpico

Alternativamente, también puedes especificar tu comentario como una opción al comando "cvs commit", sin necesidad de que lo hagas con tu editor:

Listado de Código 2.6: Realizando 'commit' de los cambios con un pequeño comentario

# cvs commit -m 'He arreglado unos pequeños y tontos errores en portage.py'

El archivo .cvsrc

Antes de continuar con otros comandos del cvs, recomiendo crear y configurar el archivo ~/.cvsrc. Con la creación de dicho archivo en tu directorio personal (~/.cvsrc), le puedes indicar las opciones para la línea de comandos que serán usadas por defecto, de manera que no tengas que escribirlas todas cada vez. Se muestra a continuación un archivo ~/.cvsrc predeterminado:

Listado de Código 2.7: Opciones recomendadas por defecto

cvs -q
diff -u -b -B
checkout -P
update -d -P

El archivo .cvsrc, continuación

Además de poder agregar ciertas opciones útiles para un par de comandos del cvs, la primer línea del .cvsrc configura a cvs en modo silencioso, que tiene como beneficio principal el hecho de que al ejecutar cvs update, la salida de este sea más conciso y legible. Además, una vez que tengas esto en el .cvsrc, puedes escribir cvs update en lugar de cvs update -dP.

Agregando un archivo al repositorio

Agregar un archivo al repositorio CVS es realmente muy fácil. Primero debes de crear el archivo con tu editor de texto favorito. Luego, tienes que escribir lo siguiente:

Listado de Código 2.8: Agregando el archivo

# cvs add myfile.c
cvs server: use 'cvs commit' to add this file permanently

Esto le dirá al cvs a que agregue este archivo al repositorio la próxima vez que tu hagas un cvs commit. Hasta tanto ocurra eso, los demás desarrolladores no podrán verlo.

Agregando un directorio al repositorio

El proceso de agregar un directorio al repositorio CVS es similar a agregar un archivo al mismo:

Listado de Código 2.9: Agregando un directorio

# mkdir foo
# cvs add foo
Directory /var/cvsroot/mycode/foo added to the repository

A diferencia de cuando se agregó el archivo, cuando agregas un directorio aparece en el repositorio inmediatamente; un cvs commit no es necesario. Una vez que hayas agregado un directorio local al repositorio, notarás que se encuentra un directorio llamado "CVS" en dicho directorio, que fue creado con el objetivo de almacenar información para el repositorio del cvs. Por ello, te puedes dar cuenta muy fácilmente si un directorio se ha agregado o no en el repositorio, simplemente te tienes que fijar si se encuentra dentro el directorio "CVS".

Notas para "cvs add"

¡Ah!, y como ya habrás adivinado, antes de agregar un archivo o directorio al repositorio, tienes que estar seguro de que sus directorios "padres" estén agregados al CVS. Caso contrario, obtendrás un error como este:

Listado de Código 2.10: Agregando un archivo, pero recibiendo un fallo

# cvs add myfile.c
cvs add: cannot open CVS/Entries for reading: No such file or directory
cvs [add aborted]: no repository

Acostumbrándonos con "cvs update", parte 1

Antes de que le echemos un vistazo a como resolver conflictos, vamos a acostumbrarnos al comando "cvs update". Si has creado el archivo ~/.cvsrc que contiene una línea "cvs -q", entonces encontrarás que la salida de "cvs update" es mucho mas fácil de leer. "cvs update" te informa acerca de que es lo que está haciendo y viendo mediante la impresión a salida de un simple carácter, un espacio y luego el nombre del archivo, por ejemplo:

Listado de Código 2.11: Actualizando CVS

# cvs update -dP
? distfiles
? packages
? profiles

Acostumbrándonos con "cvs update", parte 2

"cvs update" usa el carácter "?" para decirte que no sabe nada acerca de esos archivos en particular que se encuentra en tu copia local del repositorio. Esos archivos no son oficialmente parte del repositorio remoto, ni tampoco fueron puestos en la cola para ser agregados mas tarde. Aquí se encuentra una lista con todas las otras letras informativas que usa el CVS:

Listado de Código 2.12: Mensaje informativo: U

U [ruta]

Es usado cuando un archivo es creado en tu repositorio local, o un archivo que no fue modificado (por ti) ha sido actualizado.

Listado de Código 2.13: Mensaje informativo: A

A [ruta]

Este archivo ha sido puesto en cola para ser oficialmente agregado al repositorio cuando tú hagas un cvs commit.

Acostumbrándonos con "cvs update", parte 3

Listado de Código 2.14: Mensaje informativo: R

R [ruta]

Como "A", "R" te permite saber que este archivo ha sido puesto en cola para ser borrado. El archivo será removido del repositorio tan pronto hagas un cvs commit.

Listado de Código 2.15: Mensaje informativo: M

M [ruta]

Esto significa que este archivo ha sido modificado por ti; además, es posible que algunos cambios nuevos del repositorio hayan sido fusionado satisfactoriamente dentro del archivo.

Listado de Código 2.16: Mensaje informativo: C

C [ruta]

El carácter "C" indica que este archivo está en conflicto y requiere de trabajo manual para su arreglo antes de que puedas realizar un "cvs commit" para mandar tus cambios.

Resolviendo conflictos, introducción

Ahora veremos como resolver un conflicto. Estoy muy involucrado en el proyecto de Gentoo Linux, y nosotros tenemos nuestro servidor cvs en cvs.gentoo.org. Los desarrolladores dedicamos mucho tiempo hackeando las fuentes que se encuentras en el módulo "gentoo-x86". Dentro del módulo gentoo-x86, tenemos un archivo llamado "ChangeLog" que contiene una descripción de los cambios importantes que realizamos a los archivos en el repositorio.

Un ejemplo de "conflict"

Debido a que este archivo es modificado por casi todos los desarrolladores que realizan algún cambio importante al CVS, es una fuente primaria de conflictos -- aquí se puede encontrar un conflicto. Digamos que yo agrego las siguientes líneas en la parte superior del Changelog:

Listado de Código 2.17: Entrada de líneas a ChangeLog

día 25 Feb 2001

Esto es algo que añadí yo.

Sin embargo, digamos que antes de que yo pueda realizar mi commit, otro desarrollador agrega las siguientes líneas en la parte superior del Changelog y realiza su commit antes que yo:

Listado de Código 2.18: Entrada de líneas (2) a ChangeLog

día 25 Feb 2001

Esto es algo que hizo otro desarrollador

Un ejemplo de "conflict", continuado

Ahora, cuando yo ejecute cvs update -dP (como tendrías que hacerlo en cada commit), cvs no puede realizar la fusión de los cambios hechos en mi copia local del Changelog porque los dos hemos agregado líneas en la misma parte del mismo archivo -- ¿Cómo puede saber cvs que versión usar? Entonces, yo obtengo el siguiente error de CVS:

Listado de Código 2.19: CVS error

RCS file: /var/cvsroot/gentoo-x86/ChangeLog,v
retrieving revision 1.362
retrieving revision 1.363
Merging differences between 1.362 and 1.363 into ChangeLog
rcsmerge: warning: conflicts during merge
cvs server: conflicts found in ChangeLog
C ChangeLog

Resolución del conflicto, parte 1

Argh -- ¡un conflicto!, afortunadamente, arreglar estos conflictos es fácil. Si yo lanzo mi editor favorito, observaré el siguiente texto en la parte superior del archivo llamado Changelog:

Listado de Código 2.20: Conflicto en el ChangeLog

<<<<<<< ChangeLog
día 25 Feb 2001

Esto es algo que agregué yo.

=======
día 25 Feb 2001

Esto es algo que hizo otro desarrollador

>>>>>>> 1.363

Resolución del conflicto, parte 2

En vez de elegir una versión sobre la otra, cvs ha agregado ambas versiones en el archivo Changelog, y los marco con separadores especiales para marcar claramente el conflicto en cuestión. Ahora, está en mí el hecho de reemplazar esta región del texto que tendría que aparecer en el Changelog; en este caso, el cambio del texto no es ni una ni otra versión, sino una combinación de ambas:

Listado de Código 2.21: Entrada de líneas en el ChangeLog

date 25 Feb 2001

Esto es algo que agregué yo.

Esto es algo que hizo el otro desarrollador

Ahora que he reemplazado la región en conflicto del archivo con el texto apropiado (y borrado los marcadores "=======", etc...), puedo realizar el commit de mis cambios al cvs sin ningún tipo de problemas.

Consejos en la resolución de conflictos

Cuando necesites editar un archivo debido a conflictos, asegúrate de observar el archivo entero de manera que puedas encontrar todos los conflictos a resolver; si te olvidas de uno en particular, ¡entonces cvs no te permitirá realizar el commit hasta tanto no sea resuelto! También es muy importante remover los marcadores especiales que cvs agrega al archivo en conflicto. Otro consejo -- si cometes un error mientras estás arreglando el conflicto y luego (¡Ough!) accidentalmente grabas tus cambios, puedes encontrar la copia original de tu versión en el archivo ".#filename.version".

Borrando un archivo

Ahora es tiempo de aprender nuestra última funcionalidad de CVS -- borrar archivos del repositorio. El borrado de un archivo es un proceso de 2 pasos. Primeramente, hay que borrar el archivo de tu copia local de las fuentes, y luego ejecutar el comando cvs remove apropiadamente:

Listado de Código 2.22: Borrando un archivo

# rm myoldfile.c
# cvs remove myoldfile.c

Borrando un archivo, continuado

El archivo será luego puesto en una cola para ser luego removido del repositorio la próxima vez que se realice un commit. Una vez hecho el commit, el archivo será oficialmente borrado de la versión actual del repositorio. Sin embargo, cvs no tirará al archivo, sino que mantendrá un historial del mismo con tus contenidos, en caso de que en algún momento del futuro lo necesites. Esto es uno de las tantas maneras que cvs protege tu código fuente.

cvs remove es recursivo, lo cual significa que puedes borrar un par de archivos y luego ejecutar el comando cvs remove sin ningún otro argumento del directorio padre. Esto causará que todos los archivos borrados sean marcados para ser removidos en el próximo commit.

Borrando un directorio

Si quieres borrar un directorio entero, te recomiendo que sigas el siguiente proceso. Primero, físicamente debes de borrar todos los archivos del directorio a borrar y luego ejecutar "cvs remove" en ese directorio:

Listado de Código 2.23: Borrando un directorio

# rm *.c
# cvs remove

Borrando un directorio, continuado

Luego, debes de realizar un commit:

Listado de Código 2.24: Realizando el commit para asentar tus cambios

# cvs commit

Aquí viene el truco. Debes de seguir los siguientes pasos para borrar el directorio:

Listado de Código 2.25: Borrando el directorio

# cd ..
# cvs remove mydir
# rm -rf mydir

Observa que para borrar un directorio no es necesario realizar otro commit -- los directorios son agregados y borrados del repositorio en tiempo real.

Recuperando una versión anterior

CVS no sería un buen sistema de versionamiento si no se pudieran recuperar versiones antiguas del repositorio. Se puede recuperar archivos según una fecha específica y por supuesto, número de revisión. El siguiente ejemplo recupera la revisión 1.202 de filename y sobreescribe la versión actual de filename con esta versión:

Listado de Código 2.26: Recuperando un archivo de acuerdo a número de revisión

$ cvs update -p -r 1.202 filename > filename

Si desea recuperar un archivo de acuerdo a una fecha, use el parámetro -D. Se pueden utilizar el sello temporal entero, además de nombres relativos como ayer (yesterday) o la semana pasada (last week).

Listo!

Tu introducción al CVS ha sido completada -- Espero que este tutorial haya sido de utilidad. La información sobre CVS es mucha, más de lo que yo pueda ser capaz de cubrir en este tutorial introductorio, pero por suerte, hay grandes fuentes de información en donde puedes ampliar tus conocimientos sobre CVS:

Acerca de este documento

La versión original de este artículo fue primeramente publicado por IBM developerWorks, y es propiedad de Westtech Information Services. Este documento es una versión actualizada del artículo original, y contiene muchas mejoras hechas por el equipo de documentación de Gentoo Linux.



Imprimir

Página actualizada 20 de mayo, 2008

Esta traducción ha dejado de tener soporte

Sumario: Este tutorial introduce CVS a los lectores, el sistema de versiones concurrentes (Concurrent Versions System), que es utilizado por los desarrolladores de todo el mundo para desarrollar software en una manera flexible y colaborativa. Esta guía esta orientada para los nuevos usuarios de CVS, este tutorial mostrará una visión general tanto para usuarios como para desarrolladores. Ya sea para realizar un "check out" de las últimas fuentes disponible de un software en particular, o para empezar a utilizar CVS con el objetivo de establecerse como un desarrollador "completo", este tutorial es para ti.

Daniel Robbins
Autor

Xavier Neys
Editor

José Alberto Suárez López
Traductor

John Christian Stoddart
Traductor

José Luis Rivero
Traductor

Nicolás Miyasato
Traductor

Andrés Pereira
Traductor

Donate to support our development efforts.

Copyright 2001-2014 Gentoo Foundation, Inc. Questions, Comments? Contact us.