Uso del CVS

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

www.cvshome.org.

-----------------
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.