2.1 Der administrative Teil der Arbeitskopie

In  Kapitel 2 haben Sie schon die Grundlagen des Aufbaus einer Arbeitskopie kennen gelernt; in diesem Abschnitt werden wir ein wenig mehr ins Detail gehen. Dabei geht es hauptsächlich um die Dateien in den administrativen Unterverzeichnissen, die den Namen CVS/ tragen. Entries, Root und Repository haben Sie bereits kennen gelernt, doch in CVS/ können sich auch noch andere, von der Situation abhängige Dateien befinden. Diese Dateien werde ich jetzt beschreiben, teils, damit sie Sie nicht überraschen, wenn Sie sie antreffen, teils, damit Sie von ihnen verursachte Probleme lösen können.

CVS/Entries.Log

Gelegentlich wird eine Datei namens CVS/Entries.Log auf mysteriöse Weise erscheinen. Der einzige Zweck dieser Datei ist es, kurzzeitig kleinere Änderungen an CVS/Entries zwischenzuspeichern, und zwar so lange, bis eine Operation ansteht, die so wichtig ist, dass es sich lohnt, die gesamte Datei Entries neu zu schreiben. CVS kann Änderungen in der Datei Entries nicht an Ort und Stelle vornehmen, sondern muss, um eine Änderung vorzunehmen, die ganze Datei einlesen und wieder zurück schreiben. Um das zu vermeiden, vermerkt CVS manchmal kleine Änderungen in Entries.Log, bis es Entries das nächste Mal neu schreiben muss.

Das Format von Entries.Log ist das gleiche wie das von Entries, bis auf einen zusätzlichen Buchstaben am Anfang jeder Zeile. A bedeutet, dass die Zeile der Datei Entries hinzuzufügen ist, und R heißt, dass die Zeile entfernt werden muss.

Sie können Entries.Log fast immer ignorieren, es kommt sehr selten vor, dass ein menschliches Wesen deren Inhalt verstehen muss. Wenn Sie jedoch Entries durchgehen, um ein Problem in der Arbeitskopie zu beheben, dann sollten Sie auch Entries.Log untersuchen.

CVS/Entries.Backup

Die Datei CVS/Entries.Backup ist der Ort, wohin CVS die neue Entries-Datei schreibt, bevor es sie in Entries umbenennt. (Ähnlich wie es erst temporäre RCS-Dateien in das Archiv schreibt und sie erst, wenn sie fertig gestellt sind, an den vorgesehenen Ort verschiebt und umbenennt.) Da die Datei Entries.Backup zu Entries wird, werden Sie selten eine Datei namens Entries.Backup zu Gesicht bekommen; wenn doch, dann bedeutet das vermutlich, dass CVS inmitten einer Operation abgebrochen wurde.

CVS/Entries.Static

Wenn eine Datei CVS/Entries.Static existiert, dann heißt das, dass nicht das ganze Verzeichnis aus dem Archiv geholt wurde. (Wenn CVS weiß, dass die Arbeitskopie in einem unvollständigen Zustand ist, wird es keine zusätzlichen Dateien in das Verzeichnis bringen.)

Die Datei Entries.Static ist während eines Checkout oder eines Update vorhanden und wird sofort entfernt, wenn die Operation abgeschlossen ist. Wenn Sie also eine Datei Entries.Static sehen, dann heißt das, dass CVS unterbrochen wurde und dass deren Vorhandensein CVS vom Anlegen neuer Dateien in der Arbeitskopie abhält. (Oftmals löst der Aufruf von cvs update -d das Problem und entfernt Entries.Static.)

Bemerkung

CVS/Tag

Wenn die Datei CVS/Tag vorhanden ist, so benennt sie eine Marke, die sozusagen dem Verzeichnis zugeordnet ist. Ich sage bewusst sozusagen, da, wie Sie ja wissen, CVS keinerlei Revisionshistorie für Verzeichnisse vorhält und streng genommen auch keine Marken an ihnen anbringen kann. Marken werden nur an normale Dateien angebracht, oder, genauer gesagt, bestimmten Revisionen einer normalen Datei zugeordnet.

Wenn jedoch jede Datei in einem Verzeichnis einer bestimmten Marke zugeordnet ist, dann stellt sich CVS die Marke als auch an dem ganzen Verzeichnis angebracht vor. Wenn Sie zum Beispiel eine Arbeitskopie aus einem bestimmten Zweig per Checkout holen

und dann eine Datei hinzufügen, so ist es wünschenswert, dass die Anfangsrevision der Datei auch diesem Entwicklungszweig zugeordnet ist. Aus ähnlichen Gründen muss CVS wissen, ob das Verzeichnis eine sonstige bindende Marke 2 oder einen Datumsstempel aufweist.

Die für die Marken zuständigen Dateien (CVS/Tag) enthalten nur eine Zeile. Das erste Zeichen dieser Zeile ist ein einbuchstabiges Kürzel, das aussagt, um was für eine Marke es sich handelt; der Rest der Zeile ist der Name der Marke. Zurzeit verwendet CVS nur diese drei einbuchstabigen Kürzel:

T-Die Marke eines Zweiges

N-eine normale Marke (also nicht die Marke eines Zweiges)

D-ein bindendes Datum. So etwas tritt auf, wenn ein Kommando wie

oder

gestartet wird.

(Wenn Sie noch andere einbuchstabige Kürzel entdecken, dann heißt das, dass CVS neue Markenarten eingeführt hat, seitdem dieses Kapitel geschrieben wurde.)

Sie sollten die Datei Tag nicht von Hand entfernen; verwenden Sie besser cvs update -A.

Echte Seltenheiten

Es gibt noch andere Dateien, die Sie gelegentlich im CVS/-Unterverzeichnis vorfinden können:

CVS/Checkin.prog, CVS/Update.prog CVS/Notify, CVS/Notify.tmp CVS/Base/, CVS/Baserev, CVS/Baserev.tmp CVS/Template

Diese Dateien verursachen normalerweise keine Probleme, daher führe ich sie hier nur der Vollständigkeit halber auf (siehe  Kapitel 9 für deren vollständige Beschreibung).

Portabilität und zukünftige Erweiterungen

Jedes Mal, wenn CVS neue Features hinzugefügt werden, können neue Dateien (die ier nicht aufgeführt sind) in den administrativen Abteilungen der Arbeitskopien auftreten. Wenn es neue Dateien gibt, so werden sie wahrscheinlich im Cederqvist unter Working Directory Storage dokumentiert. Wenn Sie es vorziehen, aus dem Quelltext zu lernen, können Sie auch in src/cvs.h aus der Quelltextdistribution nachlesen.

Bedenken Sie, dass alle CVS/*-Dateien - aktuelle und zukünftige - jeweils die Zeilenendekennung verwenden, die für das lokale System der Arbeitskopie (zum Beispiel LF unter UNIX, CRLF unter Windows) angebracht ist. Das bedeutet, dass wenn Sie eine Arbeitskopie von einer Maschine auf eine andere verfrachten, CVS sie nicht mehr verarbeiten können wird. (Sie haben dann aber noch ganz andere Probleme, da die unter Revisionskontrolle stehenden Dateien selbst die für ihre neue Heimat falsche Zeilenendekennung haben werden.)

2.2 Zugriffsrechte im Archiv

CVS setzt nicht ein bestimmtes Schema bei der Vergabe der Zugriffsrechte im Archiv voraus - es kommt mit einem breiten Spektrum davon aus. Um allerdings einem verwirrenden Verhalten vorzubeugen, sollten Sie sicherstellen, dass Sie sich beim Einrichten des Archivs an die folgenden Kriterien halten:

Wenn ein Benutzer irgendeine Form des Zugriffs auf ein Unterverzeichnis im Archiv wünscht - und sei es nur lesender Zugriff - benötigt er für gewöhnlich auf Systemebene Schreibzugriff auf das Unterverzeichnis. Das ist nötig, weil CVS temporäre Lockfiles im Archiv erzeugt, um die Datenkonsistenz gewährleisten zu können. Auch reine Leseoperationen (wie checkout oder update) erzeugen Lockfiles, die anzeigen, dass die Daten, bis sie fertig sind, in ein und demselben Zustand zu bleiben haben.

Wie schon in  Kapitel 4 besprochen, kann man die Notwendigkeit der Schreibberechtigung umgehen, indem man in CVS/config den Parameter LockDir wie folgt setzt:

     
LockDir=/usr/local/cvslocks
     
     

Natürlich müssen Sie dann dafür sorgen, dass das Verzeichnis /usr/local/cvslocks für alle Benutzer von CVS schreibbar ist. In jedem Fall benötigen die meisten CVS-Operationen, auch die rein lesenden, irgendwo ein beschreibbares Verzeichnis. Als Vorgabe ist dieses Verzeichnis das des Archivs; wenn Sie sehr sicherheitsbewusst sind, dann lenken Sie es woandershin um.

Stellen Sie sicher, dass die Datei CVSROOT/history (wenn sie existiert) world-writeable3 ist. Wenn die History-Datei existiert, dann versuchen die meisten CVS-Operationen ihr einen Eintrag hinzuzufügen, und wenn dieser Versuch fehlschlägt, schlägt die ganze Operation mit einer Fehlermeldung fehl. Leider (und unerklärlicherweise) ist die History-Datei nicht von Geburt an world-writeable, wenn Sie ein neues Archiv mit cvs init erzeugen. Zumindest bei der derzeit aktuellen CVS-Version sollten Sie deren Zugriffsrechte direkt nach dem Erzeugen des neuen Archivs ändern (oder die Datei einfach entfernen, wenn Sie das Speichern der Projekthistorie gänzlich unterbinden wollen).

Bemerkung

Aus Sicherheitsgründen sollten Sie dafür sorgen, dass die meisten Benutzer von CVS auf Unix-Ebene keinen Schreibzugriff auf das CVSROOT-Verzeichnis haben. Wenn jemand Checkin-Zugriff auf CVSROOT hat, dann kann er commitinfo, loginfo oder beliebige andere triggernde Dateien so anpassen, dass beliebige Programme seiner Wahl aufgerufen werden, er könnte sogar ein neues Programm mit einem Commit in das System bringen, wenn das, was er haben möchte, sich noch nicht dort befindet. Sie sollten daher davon ausgehen, dass jeder, der Commit- Zugang zu CVSROOT hat, in der Lage ist, beliebige Kommandos im System abzusetzen.