Node:Formato RCS, Next:Qu� ocurre cuando elimina un fichero, Previous:Estructura del repositorio, Up:Administracion del Repositorio
No necesita conocer nada del formato RCS para usar CVS (aunque hay un
escrito excelente incluido en la distribuci�n fuente, vea doc/RCSFILES).
Sin embargo, una comprensi�n b�sica del formato puede ser de inmensa
ayuda para resolver problemas con CVS, as� que echaremos un peque�o vistazo
a uno de los ficheros, hello.c,v. Aqu� est� su contenido:
head 1.1;
branch 1.1.1;
access ;
symbols start:1.1.1.1 jluis:1.1.1;
locks ; strict;
comment @ * @;
1.1
date 99.06.20.17.47.26; author jluis; state Exp;
branches 1.1.1.1;
next;
1.1.1.1
date 99.06.20.17.47.26; author jluis; state Exp;
branches ;
next;
desc
@@
1.1
log
@Initial revision
@
text
@#include <stdio.h>
void
main ()
{
printf ("�Hola, mundo!\n");
}
@
1.1.1.1
log
@importaci�n inicial a CVS
@
text
@@
�Uff! La mayor�a de esto se puede ignorar; no hace falta que se preocupe
de la relaci�n entre 1.1 y 1.1.1.1, por ejemplo, o de la rama implicada 1.1.1
- en realidad no son significativas, desde un punto de vista del usuario o
incluso del administrador. Lo que deber�a comprender es el formato en general.
Al comienzo hay una colecci�n de cabeceras:
head 1.1; branch 1.1.1; access ; symbols start:1.1.1.1 jluis:1.1.1; locks ; strict; comment @ * @;
M�s abajo hay grupos de metainformaci�n sobre cada revisi�n (pero a�n sin
mostrar el contenido de esa revisi�n), como:
1.1 date 99.06.20.17.47.26; author jluis; state Exp; branches 1.1.1.1; next ;
Y finalmente, el informe de cambios ("log message", N. del T.) y texto de una
revisi�n real:
1.1
log
@Initial revision
@
text
@#include <stdio.h>
void
main ()
{
printf ("�Hola, mundo!\n");
}
@
1.1.1.1
log
@importaci�n inicial a CVS
@
text
@@
Si lo mira de cerca ver� que el contenido de la primera revisi�n se
guarda bajo la cabecera 1.1, pero en ella el informe de cambios es "Initial
revision", mientras que el mensaje que usamos en realidad a la hora de
importar fue "importaci�n inicial a CVS". No es necesario que se preocupe
por esta discrepancia ahora. Ocurre porque las importaciones son
circunstancias especiales: para que importaciones repetidas en el
mismo proyecto tengan un efecto �til, la importaci�n en realidad coloca
la revisi�n inicial en el tronco principal y en una rama especial (las
razones para ello se aclarar�n cuando veamos derivaciones comerciales
en CVS avanzado). Por ahora puede tratar 1.1 y
1.1.1.1 como la misma cosa.
El fichero se vuelve a�n m�s revelador despu�s de que enviemos con commit
la primera modificaci�n a hello.c:
floss$ cvs -Q co miproyecto
floss$ cd miproyecto
floss$ emacs hello.c
(haga algunos cambios al fichero)
floss$ cvs ci -m "ahora tambi�n dice adi�s"
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/nuevorepos/miproyecto/hello.c,v <-- hello.c
new revision: 1.2; previous revision: 1.1
done
Si mira en el repositorio a hello.c,v ver� el efecto del env�o de cambios:
head 1.2;
access;
symbols
start:1.1.1.1 jluis:1.1.1;
locks; strict;
comment @ * @;
1.2
date 99.06.21.01.49.40; author jluis; state Exp;
branches;
next 1.1;
1.1
date 99.06.20.17.47.26; author jluis; state Exp;
branches
1.1.1.1;
next ;
1.1.1.1
date 99.06.20.17.47.26; author jluis; state Exp;
branches;
next ;
desc
@@
1.2
log
@ahora tambi�n dice adi�s
@
text
@#include <stdio.h>
void
main ()
{
printf ("�Hola, mundo!\n");
printf ("�Adi�s, mundo!\n");
}
@
1.1
log
@Initial revision
@
text
@d7 1
@
1.1.1.1
log
@importaci�n inicial a CVS
@
text
@@
Ahora el contenido completo de la revisi�n 1.2 est� guardado en el fichero,
y el texto para la revisi�n 1.1 ha sido reemplazado por la f�rmula cr�ptica:
d7 1
El d7 1 es un c�digo diff que quiere decir "empezando en la l�nea 7,
borrar 1 l�nea". En otras palabras, �para obtener la Revisi�n 1.1, borre la
l�nea 7 de la Revisi�n 1.2! Pru�belo usted mismo. Ver� que de hecho produce
la Revisi�n 1.1 - simplemente se deshace de la l�nea que a�adimos al fichero.
Esto demuestra el principio b�sico del formato RCS: Almacena s�lo las diferencias entre revisiones, ahorrando con ello un mont�n de espacio comparado con guardar cada revisi�n entera. Para volver desde la �ltima revisi�n a la anterior, parchea la �ltima revisi�n usando el diff almacenado. Por supuesto, esto significa que cuanto m�s hacia atr�s viaje en la historia de revisiones, habr� que realizar m�s operaciones de parcheo (por ejemplo, si el fichero est� en la Revisi�n 1.7 y a CVS se le pide que muestre la Revisi�n 1.4, tendr� que producir la 1.6 parcheando hacia atr�s la 1.7, luego la 1.5 parcheando la 1.6, y finalmente la 1.4 parcheando la 1.5). Por suerte, las revisiones antiguas son adem�s las menos solicitadas, as� que el sistema RCS funciona bastante bien en la pr�ctica: Cuanto m�s reciente sea una revisi�n, m�s "barata" es de obtener.
En cuanto a la informaci�n de cabecera al principio del fichero, no necesita saber lo que significa todo ello. Sin embargo, los efectos de ciertas operaciones se muestran muy claramente en las cabeceras, y una peque�a familiaridad con ellas puede resultar �til.
Cuando env�a cambios de una nueva revisi�n al tronco, la etiqueta head
se actualiza (note c�mo cambi� a 1.2 en el ejemplo anterior, cuando se envi� el
cambio de la segunda revisi�n a hello.c). Cuando a�ade un fichero como binario
o lo marca, esas operaciones se registran tambi�n en las cabeceras. Como
ejemplo, vamos a a�adir foo.jpg como fichero binario para despu�s marcarlo
un par de veces:
floss$ cvs add -kb foo.jpg cvs add: scheduling file 'foo.jpg' for addition cvs add: use 'cvs commit' to add this file permanently floss$ cvs -q commit -m "a�adida una imagen aleatoria; pregunte a \ jluis@red-bean.com el motivo" RCS file: /usr/local/nuevorepos/miproyecto/foo.jpg,v done Checking in foo.jpg; /usr/local/nuevorepos/miproyecto/foo.jpg,v <-- foo.jpg initial revision: 1.1 done floss$ cvs tag alguna_marca_aleatoria foo.jpg T foo.jpg floss$ cvs tag OTRA-MARCA foo.jpg T foo.jpg floss$
Examine ahora la secci�n "header" de foo.jpg,v en el repositorio:
head 1.1;
access;
symbols
OTRA-MARCA:1.1
alguna_marca_aleatoria:1.1;
locks; strict;
comment @# @;
expand @b@;
F�jese en la b en la l�nea "expand" del final - se debe a haber usado el par�metro -kb al a�adir el fichero, y quiere decir que el fichero no sufrir� expansiones de palabra clave o nueva l�nea, que ocurrir�an normalmente durante obtenciones de copia y actualizaciones si fuera un fichero de texto normal. Las marcas aparecen en la secci�n "symbols", una por l�nea - ambas est�n asociadas a la primera revisi�n, puesto que eso es lo que se marc� ambas veces. (Esto tambi�n ayuda a explicar por qu� los nombres de marca pueden s�lo contener letras, n�meros, guiones y guiones bajos. Si la propia marca contuviera puntos o comas, su registro RCS podr�a ser ambiguo, porque no habr�a forma de encontrar el enlace textual entre la marca y la revisi�n a la que est� asociada.)
El s�mbolo @ se usa como delimitador de campos en los ficheros RCS, lo
que significa que si aparece alguno en el texto de un fichero o en un informe
de cambios, deber� estar comentado (de lo contrario, CVS interpretar�a
incorrectamente que est� marcando el final de ese campo). Se comenta
poni�ndolo doble - es decir, CVS siempre interpreta @@ como un
"signo @ literal", nunca como un "fin de campo actual". Cuando enviamos los
cambios a foo.jpg, el informe de cambios fue
"a�adida una imagen aleatoria; pregunte a jluis@red-bean.com el motivo"
que se almacena en foo.jpg,v as�:
1.1 log @a�adida una imagen aleatoria; pregunte a jluis@@red-bean.com el motivo @
El signo @ en jluis@@red-bean.com se descomentar� autom�ticamente
cada vez que CVS obtenga el informe de cambios:
floss$ cvs log foo.jpg
RCS file: /usr/local/nuevorepos/miproyecto/foo.jpg,v
Working file: foo.jpg
head: 1.1
branch:
locks: strict
access list:
symbolic names:
OTRA-MARCA: 1.1
alguna_marca_aleatoria: 1.1
keyword substitution: b
total revisions: 1; selected revisions: 1
description:
----------------------------
revision 1.1
date: 1999/06/21 02:56:18; author: jluis; state: Exp;
a�adida una imagen aleatoria: pregunte a jluis@red-bean.com el motivo
============================================================================
floss$
El �nico motivo por el que deber�a preocuparse es por si alguna vez tiene que editar a mano ficheros RCS (una circunstancia rara, aunque le ha pasado a m�s de uno) Debe acordarse entonces de usar signos dobles @ en contenidos de la revisi�n e informes de cambios. Si no lo hace, el fichero RCS estar� corrupto y probablemente tendr� un comportamiento extra�o e indeseable.
Hablando de editar a mano ficheros RCS, no se deje enga�ar por los
permisos en el repositorio:
floss$ ls -l total 6 -r--r--r-- 1 jluis users 410 Jun 20 12:47 README.txt,v drwxrwxr-x 3 jluis users 1024 Jun 20 21:56 a-subdir/ drwxrwxr-x 2 jluis users 1024 Jun 20 21:56 b-subdir/ -r--r--r-- 1 jluis users 937 Jun 20 21:56 foo.jpg,v -r--r--r-- 1 jluis users 564 Jun 20 21:11 hello.c,v floss$
(Para los que no est�n familiarizados con la salida de "ls" en Unix, las
l�neas -r--r--r-- de la izquierda b�sicamente quieren decir que los
ficheros se pueden leer pero no cambiar.) Aunque los ficheros parecen ser
de s�lo lectura para todos, tambi�n hay que tener en cuenta los permisos
de directorio:
floss$ ls -ld . drwxrwxr-x 4 jluis users 1024 Jun 20 22:16 ./ floss$
El propio directorio miproyecto/ - y sus subdirectorios - es accesible para escritura por el propietario (jluis) y el grupo (users). Esto significa que CVS (ejecut�ndose como jluis o como cualquiera del grupo users) puede crear y borrar ficheros en esos directorios, incluso si no puede editar directamente los ficheros a presentes. CVS edita un fichero RCS haciendo una copia separada de �l, de forma que usted haga todos sus cambios en una copia temporal, y luego reemplaza el fichero RCS existente con el nuevo. (Pero por favor, no pregunte por qu� los ficheros son de s�lo lectura - hay razones hist�ricas para ello, relacionadas con la forma en que RCS trabaja cuando se ejecuta como programa en solitario.)
Por cierto, puede que usted no desee que el grupo de los ficheros sea
users, considerando que el directorio ra�z del repositorio se le
asign� expl�citamente el grupo cvs. Puede corregir el problema
ejecutando esta orden dentro del repositorio:
floss$ cd /usr/local/nuevorepos floss$ chgrp -R cvs miproyecto
Las reglas habituales Unix de creaci�n de ficheros rigen qu� grupo se
asigna a los nuevos ficheros que aparecen en el repositorio, as� que
de vez en cuando puede que necesite ejecutar "chgrp" o "chmod" en ciertos
ficheros o directorios del repositorio (ajustar el bit SGID con
chmod g+s es a menudo una buena estrategia: hace que los hijos
de un directorio hereden el grupo propietario del directorio, que por lo
general es lo que quiere que pase en el repositorio). No hay reglas
r�pidas acerca de c�mo deber�a estructurar los permisos del repositorio;
depende de qui�n est� trabajando en qu� proyectos.