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.