Node:Números de revisión, Next:Detección y resolución de conflictos, Previous:Enviar cambios al repositorio, Up:Un día con CVS
Cada fichero en un proyecto tiene su propio número de revisión. Cuando un fichero es enviado al repositorio, la última parte del número de revisión se incrementa en una unidad. Por tanto, los diferentes ficheros que forman parte de un proyecto pueden tener siempre números de revisión (a veces muy) diferentes. Esto sólo significa que algunos ficheros han sido modificados (e incorporados en el repositorio) con más frecuencia que otros.
En este momento quizás se pregunte qué sentido tiene la parte situada a la izquierda del punto decimal, cuando la única parte que cambia es la situada a la derecha. Pues bien, a pesar de que CVS nunca incrementa automáticamente el número situado a la izquierda, este número puede ser incrementado a petición del usuario. Esto es algo que se usa en muy contadas ocasiones, y no lo cubriremos en esta guía.
Volviendo al tema, en el proyecto de ejemplo que hemos estado usando,
acabábamos de enviar al repositorio los cambios que habíamos realizado
en tres ficheros. Cada uno de estos ficheros es ahora la revisión 1.2,
pero el resto de ficheros del proyecto son aún la revisión 1.1. Cuando
usted solicita al repositorio una copia de un proyecto, siempre obtiene
la última revisión de cada fichero allí presente. Esto es lo que el usuario
mperez vería si ahora mismo solicitase una copia de miproyecto y observase
los números de revisión del directorio raíz:
paste$ cvs -q -d :pserver:mperez@cvs.foobar.com:/usr/local/cvs co miproyecto U miproyecto/README.txt U miproyecto/hello.c U miproyecto/a-subdir/loquesea.c U miproyecto/a-subdir/subsubdir/fish.c U miproyecto/b-subdir/random.c paste$ cd miproyecto/CVS paste$ cat Entries /README.txt/1.1.1.1/Sun Apr 18 18:18:22 1999// /hello.c/1.2/Mon Apr 19 06:35:15 1999// D/a-subdir//// D/b-subdir//// paste$
El fichero hello.c (entre otros) se encuentra ahora en su revisión 1.2, mientras que el fichero README.txt está aún en la revisión inicial (1.1.1.1, también conocida como 1.1).
Si mperez añade ahora la línea
printf ("entre hola y adiós\n");
a hello.c y lo envía, el número de revisión del fichero se incrementará
una vez más:
paste$ cvs ci -m "añadida una nueva línea entremedias" cvs commit: Examining . cvs commit: Examining a-subdir cvs commit: Examining a-subdir/subsubdir cvs commit: Examining b-subdir Checking in hello.c; /usr/local/cvs/miproyecto/hello.c,v <-- hello.c new revision: 1.3; previous revision: 1.2 done paste$
Ahora hello.c está en la revisión 1.3, fish.c y random.c están aún en la revisión 1.2, y los demás ficheros en la revisión 1.1.
Observe que el comando fue dado como cvs ci en lugar de cvs commit. La
mayor parte de los comandos CVS tienen una forma abreviada, para hacer
más fácil el escribirlos. Para checkout, update y commit, las versiones
abreviadas son co, up y ci, respectivamente. Puede obtener una lista de
todas las formas abreviadas ejecutando el comando cvs --help-synonyms.
Normalmente puede ignorar el número de revisión de un fichero. En la mayoría de los casos, estos números son simplemente anotaciones internas que CVS gestiona automáticamente. Sin embargo, ser capaz de encontrar y comparar números de revisión es algo muy útil cuando tiene que obtener (o establecer diferencias respeto a) una copia antigua del fichero.
Examinar el fichero Entries no es la única forma de descubrir un número
de revisión. Puede usar también el comando status:
paste$ cvs status hello.c =================================================================== File: hello.c Status: Up-to-date Working revision: 1.3 Tue Apr 20 02:34:42 1999 Repository revision: 1.3 /usr/local/cvs/miproyecto/hello.c,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none)
el cual, cuando se invoca sin nombrar ningún fichero, muestra el estado
de todos los ficheros que conforman el proyecto:
paste$ cvs status
cvs status: Examining.
===================================================================
File: README.txt Status: Up-to-date
Working revision: 1.1.1.1 Sun Apr 18 18:18:22 1999
Repository revision: 1.1.1.1 /usr/local/cvs/miproyecto/README.txt,v
Sticky Tag: (none)
Sticky Date: (none)
Sticky Options: (none)
===================================================================
File: hello.c Status: Up-to-date
Working revision: 1.3 Tue Apr 20 02:34:42 1999
Repository revision: 1.3 /usr/local/cvs/miproyecto/hello.c,v
Sticky Tag: (none)
Sticky Date: (none)
Sticky Options: (none)
cvs status: Examining a-subdir
===================================================================
File: loquesea.c Status: Up-to-date
Working revision: 1.1.1.1 Sun Apr 18 18:18:22 1999
Repository revision: 1.1.1.1 /usr/local/cvs/miproyecto/a-subdir/loquesea.c,v
Sticky Tag: (none)
Sticky Date: (none)
Sticky Options: (none)
cvs status: Examining a-subdir/subsubdir
===================================================================
File: fish.c Status: Up-to-date
Working revision: 1.2 Mon Apr 19 06:35:27 1999
Repository revision: 1.2 /usr/local/cvs/miproyecto/
a-subdir/subsubdir/fish.c,v
Sticky Tag: (none)
Sticky Date: (none)
Sticky Options: (none)
cvs status: Examining b-subdir
===================================================================
File: random.c Status: Up-to-date
Working revision: 1.2 Mon Apr 19 06:35:27 1999
Repository revision: 1.2 /usr/local/cvs/miproyecto/b-subdir/random.c,v
Sticky Tag: (none)
Sticky Date: (none)
Sticky Options: (none)
paste$
Limítese a ignorar las partes de la salida que no entienda; de hecho, éste es por regla general un buen consejo al utilizar CVS. A menudo, el pequeño trozo de información que está buscando vendrá acompañado de otra mucha información que no le interesa, y que quizás ni siquiera comprenda. Esta situación es normal; simplemente tome lo que necesite y olvídese de todo lo demás.
En el ejemplo anterior, las partes que nos interesan son las primeras
tres líneas (sin contar la línea en blanco) de la información de estado
de cada fichero. La primera línea es la más importante, puesto que le dice
el nombre del fichero y su estado en la copia de trabajo. Todos los ficheros
están en este momento sincronizados con el repositorio, así que todos dicen
Up-to-date. Sin embargo, si random.c hubiera sido modificado y el cambio
no se hubiese enviado al repositorio, podríamos encontrarnos algo como esto:
=================================================================== File: random.c Status: Locally Modified Working revision: 1.2 Mon Apr 19 06:35:27 1999 Repository revision: 1.2 /usr/local/cvs/miproyecto/b-subdir/random.c,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none)
Los números de revisión de la copia de trabajo y de la copia presente
en el repositorio le informan de si el fichero está o no sincronizado
con la copia que hay en el repositorio. Volviendo a nuestra copia de
trabajo original (la copia de jluis, que no ha visto todavía el cambio
habido en hello.c), vemos lo siguiente:
floss$ cvs status hello.c =================================================================== File: hello.c Status: Needs Patch Working revision: 1.2 Mon Apr 19 02:17:07 1999 Repository revision: 1.3 /usr/local/cvs/miproyecto/hello.c,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) floss$
Esto nos dice que alguien ha efectuado cambios en hello.c, elevando a 1.3 el número de revisión de la copia que hay en el repositorio, y que esta copia de trabajo está aún en la revisión 1.2. La línea "Status: Needs Patch" significa que la siguiente actualización traerá los cambios del repositorio y los aplicará a la copia de trabajo del fichero.
Supongamos por un momento que ignoramos completamente el cambio que mperez ha hecho a hello.c, así que no utilizamos status ni update, sino que simplemente procedemos a editar nuestro fichero local, realizando un cambio ligeramente distinto en el mismo punto del fichero. Esto nos lleva a nuestro primer conflicto.