Node:La Copia de Trabajo del Área Administrativa, Next:, Up:Causas Usualmente Sospechosas


La Copia de Trabajo del Área Administrativa

Ya vimos la estructura de la copia de trabajo en Una introduccion a CVS; en esta sección entraremos un poco más en detalle. Casi todos los detalles conciernen a los ficheros de los directorios administrativos bajo CVS/. Ya conocemos los ficheros Entries, Root y Repository, pero en el directorio CVS/ también puede haber otros ficheros, según las circunstancias. Describiré esos ficheros aquí, parcialmente para que no nos sorprenda encontrarlos, y también para que sepamos cómo corregir errores que eventualmente se produzcan en ellos.

CVS/Entries.Log

A veces, aparecerá un extraño fichero CVS/Entries.Log. El único propósito de este fichero es hacer de cache temporal de los cambios menores de CVS/Entries, hasta que haya suficientes cambios acumulados para modificar este fichero. CVS no es capaz de editar directamente el fichero Entries, por el contrario tiene que leerlo y sobreescribirlo por completo para cualquier cambio. Para evitar excesiva carga, CVS a veces guarda los cambios pequeños en Entries.log, hasta la próxima vez que necesite reescribir el fichero Entries.

El formato de Entries.log es como el de Entries, salvo que además incluye una letra al principio de cada línea. A significa que la línea será añadida al fichero Entries, y R significa que esa línea será borrada.

Casi siempre podemos ignorar el fichero Entries.log; es raro que un administrador tenga que entender la información que contiene. Sin embargo, si estamos depurando algún problema que nos pide examinar el fichero Entries, probablemente tengamos que echar un vistazo también a Entries.log.

CVS/Entries.Backup

El fichero CVS/Entries.backup es el que usa CVS para escribir un fichero Entries nuevo, antes de renombrarlo a Entries (similarmente al mecanismo de escribir en ficheros temporales RCS y luego renombrarlos convenientemente). Debido a que se renombra a Entries cuando está acabado, serán pocas las veces que veremos el fichero Entries.Backup; si lo vemos alguna vez se deberá probablemente a la interrupción de un proceso CVS en medio de alguna operación.

CVS/Entries.Static

Si existe el fichero CVS/Entries.Static, significa que el directorio completo no ha sido extraido del repositorio. (Cuando CVS sabe que un directorio está en un estado incompleto, él no añadirá ficheros adicionales a ese directorio.)

El fichero Entries.Static existe durante las operaciones de checkout y actualización, y se borra inmediatamente al completar la operación. Si vemos el fichero, significará que CVS fue interrumpido, y su existencia impide a CVS crear cualquier fichero nuevo en la copia de trabajo. (Ahora bien , ejecutando cvs update -d se soluciona el problema y se borra Entries.Static.)

La ausencia de Entries.Static no implica necesariamente que la copia de trabajo incluya todos los ficheros del proyecto. Tan pronto se crea un nuevo directorio en el repositorio del proyecto, y alguien actualiza su copia sin incluir el flag -d a la orden update, el nuevo directorio no se creará en la copia de trabajo. Localmente, CVS no sabe que existe el nuevo directorio, luego él mismo borrará el fichero Entries.Static cuando la actualización termine, aunque el nuevo directorio no se haya creado en la copia de trabajo.

CVS/Tag

Si existe el fichero CVS/Tag, nombrará a un tag asociado, en cierto sentido, con el directorio. Digo "en cierto sentido" ya que, como sabemos, CVS no mantiene información sobre versiones de directorios y, hablando con precisión, no puede asociar tags a ellos. Los tags se asocian solo a ficheros normales o, más precisamente, a revisiones concretas de ficheros normales.

Sin embargo, si cada fichero de un directorio está en un tag concreto, CVS presupone que el directorio también está en ese tag. Por ejemplo, si íbamos a extraer de CVS una copia de trabajo de una rama concreta: 

floss$ cvs co -r Bugfix_Rama_1

y luego insertamos un fichero en ella, querremos que la versión inicial del fichero esté en esa rama también. Por razones similares, CVS también necesita conocer si el directorio tiene un tag de que no es rama (non-branch) o la fecha puesta en él.

Los ficheros de tags contienen una línea. El primer carácter de la línea es un código de una letra que indica qué clase de tag es, y el resto es el nombre del tag. Actualmente, CVS solo utiliza las siguientes tres letras como código:

(Si vemos cualquier otro código de una letra, simplemente nos indicará que CVS ha añadido un nuevo tipo de tag posteriormente a la escritura de este libro.)

El fichero Tag no debe ser borrado manualmente; en su lugar use cvs update -A.

Rarezas

Hay otros ficheros que ocasionalmente se encontrarán en un directorio CVS/:

Estos ficheros no son, normalmente, causa de problemas, por lo que simplemente los vamos a listar (véase Referencia de CVS para conocer su significado completo).

Portabilidad y extensiones futuras.

Conforme se añadan nuevas características a CVS, podrán aparecer nuevos ficheros (no listados aquí) en las áreas administrativas. Conforme dichos ficheros sean añadidos, probablemente serán documentados en el manual de Cederqvist, en la sección Working Directory Storage. También podemos mirar en el código fuente, en src/cvs.h, si preferimos aprender a partir de las fuentes.

Finalmente, observemos que todos los ficheros CVS/* - actuales y futuros - siguen las convenciones de final de línea apropiadas al sistema en uso (por ejemplo, LF para Unix o CR/LF para Windows). Esto significa que si llevamos una copia de trabajo desde una plataforma a otra, puede suceder que CVS no pueda manejarla (además, podemos tener otros problemas, debido a que los ficheros controlados por el sistema de versiones pueden tener ellos mismos un fin de línea inapropiado).