Lo que sigue la transcripción del mail que da una somera
explicación de los primeros pasos
necesarios para compartir los
archivos del "paper 1" en CVS.
No pretende ser una explicación exhaustiva. Todo lo que hay que
saber está en
----------------- Puse el paper que Mario empezó a escribir en CVS para que podamos todos editar sin conflictos y guardar versiones anteriores, a medida que vayamos modificando los archivos. Lo que puse es lo que Mario escribió. Yo mandaré mi parte directamente al CVS una vez que la tenga mas o menos lista. El depósito o "repository" está situado en /csp1/cvsroot/. El "proyecto" correspondiente a este paper está en un subdirectorio que se llama paper1/. No hay que tocar nada en ese directorio. Con CVS nos encargaremos de hacernos una copia de trabajo para cada uno y de actualizar los cambios que hagamos (ver más abajo). Un punto a notar es que debemos usar CVS desde una máquina que "vea" el directorio /csp1/. Es decir, csp1, csp2 y csp3 (creo). Existe la manera de usar CVS en forma remota, por ejemplo desde oveja, pero no he llegado a tal nivel de comprensión del CVS. Está todo explicado en el manual de CVS, sección 2.9, pero veamos antes si es realmente necesaria esta opción. --- Lo primero que hay que hacer es bajarse una copia de lo que está en el depósito del CVS ("repository") a un directorio de trabajo acorde en nuestra máquina. (Mario, ojo en este paso con borrar lo que ya tienes). El siguiente ejemplo puede servir de guía: - Pararse en un directorio creado para el caso: cd /data/gaston/csp o cd ~/papers - Bajar una copia del repository (o "hacer un 'checkout'"): cvs -d /csp1/cvsroot checkout paper1 Esto crea un subdirectorio paper1/ en /data/gaston/csp. Se puede revisar lo que ese subdir contiene. Nota: el directorio creado contiene los archivos '.tex' en paper1/ y las figuras separadas en un subdir llamado figures/. Los comandos 'plotone' en 'paper.tex' fueron modificados acordemente para que latex encuentre las figuras. Si esta configuracion no les parece conveniente, lo podemos cambiar. A mi me pareció más prolijo así. Nota 2: Lo único que falta para poder compilar el paper es el archivo de clase 'aastex.cls', que pongo en el att. de este mail y que no puse en el repository porque no es un archivo que vayamos a modificar nosotros. Lo que hay que hacer es copiar el 'aastex.cls' en el mismo directorio paper1/ y correr latex como siempre. Nota 3: con lo dicho en la nota 2, se puede ver que no necesariamente todo archivo que tengamos en nuestra copia de trabajo debe estar en el repository. Sólo conviene poner en el repository aquellos archivos que vayamos a editar en conjunto. Por ejemplo, tampoco querremos que los archivos que produce latex (*.aux, *.log, *.dvi, etc.) estén en el repository, aunque sí estén en nuestras copias de trabajo. - Los cambios que hagamos en cualquier archivo compartido deben ser enviados al repository para que los demas los vean. Eso se hace con 'commit' (estando parados en nuestro directorio de trabajo): cvs commit -m "Cambié tal y tal cosa, bla, bla, bla..." Lo que viene despues de la -m es un comentario que debe estar. Si uno no lo pone, el CVS abre un editor para que pongamos un comentario... Conviene verificar al menos que la copia que estemos mandando compile sin problemas, para que no se esparsan los errores. El comando 'commit' como está arriba intenta enviar al repository TODOS los archivos del directorio que estén compartidos en CVS. Como alternativa, se puede hacer el envío de archivos individuales, por ej.: cvs commit -m "un archivo solo..." archivo.tex El número de versión actual de cada archivo aparece en la pantalla. - Los demás verán nuestros cambios cuando hagan una actualización (update), estando siempre parados en el directorio de trabajo: cvs update Nota: 'checkout' se hace una sola vez por "proyecto". 'Update' se repite para bajar cada versión nueva de los archivos. - Para evitar conflictos, conviene verificar que tengamos la última versión de cada archivo antes de hacer un commit. Por lo cual, es recomendable hacer: cvs update (verificar que no haya conflictos o corregirlos) cvs commit -m "..." La interpretación de la salida de 'update' es más compleja de lo que yo conozco y no puedo resumirla mucho acá. Ver sección A.17.2, página 122 del manual de CVS. Lo que sé es que existen letras que dicen el estado de cada archivo. Algunas de estas letras son: U: actualizado sin problemas A: archivo agregado R: archivo borrado M: el archivo en tu directorio de trabajo era distinto del del repository, pero los dos se pudieron unir sin conflictos. C: No se pudo unir tu versión con la del repository porque hubo un conflicto (por ej., misma línea modificada de dos maneras distintas). El archivo en nuestra copia de trabajo queda con marcas del tipo '<<<<<<', '=======' y '>>>>>>', rodeando las líneas que tuvieron conflicto. Hay que editar el archivo, poner lo que sea correcto en esas líneas, borrar las marcas y volver a hacer commit. (Ver claro ejemplo en sección 10.3, página 65 del manual de CVS). - Se puede mirar el estado de cada archivo haciendo: cvs status - Si queremos agregar archivos nuevos al repository, debemos hacer lo siguiente, por ej., para agregar 'archivo.tex': cvs add archivo.tex cvs commit -m "Agregue un archivo nuevo, etc., etc." (Lo segundo hace efectiva la inclusion del archivo al repository, para que todos lo adquieran al hacer un 'update'). - Para quitar un archivo del CVS, primero hay que borrarlo de nuestra copia de trabajo y después decirle a CVS que lo saque. Por ej.: rm archivo.tex cvs remove archivo.tex cvs commit -m "Borre tal archivo ..." - Para terminar, el apéndice B del manual de CVS da una referencia rápida de los comandos CVS y sus opciones.