Node:Exportar para distribución pública, Next:, Previous:Vigilando fuentes de terceras partes (Derivaciones comerciales), Up:CVS avanzado


Exportar para distribución pública

CVS es un buen mecanismo de distribución para desarrolladores, pero la mayoría de usuarios obtendrán el software a través de un paquete descargable. Este paquete normalmente no es una copia de trabajo de CVS; es un árbol de código que puede ser fácilmente configurado y compilado en el sistema del usuario.

Sin embargo, CVS ofrece un mecanismo que ayuda a crear ese paquete, la orden cvs export (Exportar). Exportar un proyecto es como obtener una copia de trabajo del proyecto, excepto que se obtiene el directorio completo del proyecto sin los subdirectorios administrativos. O sea, que no obtiene una copia de trabajo sino el código fuente completo que no sabe nado sobre dónde vino o que versiones de CVS tienen sus ficheros. Así la copia exportada es como lo que el público ve cuando descarga y desempaqueta un distribución. Asumiendo que el proyecto está organizado para que sea directamente compilable desde la copia de trabajo (y así es como debería estar), entonces todavía será compilable en la copia exportada.

La orden export funciona igual que checkout, excepto que requiere una etiqueta o fecha. Por ejemplo, aquí hemos etiquetado el proyecto con un nombre para el lanzamiento final y hemos exportado basándonos en eso: 

floss$ pwd
/home/jrandom/myproj
floss$ cvs -q tag R_1_0
T README.txt
T hello.c
T a-subdir/whatever.c
T a-subdir/subsubdir/fish.c
T b-subdir/random.c
floss$ cd ..
floss$ cvs -d /usr/local/newrepos -q export -r R_1_0 -d myproj-1.0 myproj
U myproj-1.0/README.txt
U myproj-1.0/hello.c
U myproj-1.0/a-subdir/whatever.c
U myproj-1.0/a-subdir/subsubdir/fish.c
U myproj-1.0/b-subdir/random.c
floss$ cd myproj-1.0
floss$ ls
README.txt  a-subdir  b-subdir  hello.c

Observe que como la export no es llamada desde una copia de trabajo ha sido necesario usar la opción global -d para decirle a CVS qué repositorio usar. En este ejemolo en particular, además, exportamos a un directorio explícitamente nombrado (myproj-1.0) en vez del directorio por defecto con el nombre del proyecto (myproy, porque ya había una copia con ese nombre presente. Esta situación no es infrecuente.

Después de crear la copia mediante export, como en el ejemplo anterior, lo que sigue es suficiente para completar la entrega final si el proyecto es sencillo: 

floss$ tar cf myproj-1.0.tar myproj-1.0
floss$ gzip --best myproj-1.0.tar
floss$ ls
myproj/   myproj-1.0/   myproj-1.0.tar.gz
floss$ rm -rf myproj-1.0
floss$ mv myproj-1.0.tar.gz /home/ftp/pub/myproj/

Ejecutar todas estas órdenes a mano es raro. Lo normal es que cvs export sea llamada desde una rutina que maneje todos los aspectos de la entrega final y el proceso de empaquetado. Debido a que hay varias entregas de prueba antes del lanzamiento final es deseable que los procedimientos para crear un paquete se automatizen.