CVS ist ein System, mit dem sich alle Arten von Dokumenten und Dateien verwalten lassen, die in einem Team von mehreren Leuten bearbeitet werden sollen. Hierzu gehören z.B. Quelldateien von Programmen, Dokumentationen oder auch Bücher. CVS sorgt dafür, dass Änderungen eines Projektes, die von verschiedenen Teammitgliedern ausgeführt werden, nicht durcheinandergeraten.

Zu diesem Zweck werden alle Dateien eines solchen Projektes von CVS in einem zentralen Repository gehalten. Will jemand mit diesen Dateien arbeiten, so müssen diese zuerst aus dem Repository in den eigenen Arbeitsbreich kopiert werden.

Wenn die Arbeit an den Dateien beendet ist, müssen diese wieder zurück in das Repository gestellt werden. Hier kommt der eigentliche Nutzen von CVS zum Tragen, denn CVS sorgt dafür, dass diese Änderungen nicht dazu führen, dass zwischenzeitlich gemachte Änderungen anderer Teammitglieder verloren gehen. Zu diesem Zweck führt CVS über alle Änderungen Buch und informiert das Teammitglied gegebenenfalls darüber, wenn in der Zwischenzeit Änderungen an der bearbeiteten Datei durchgeführt wurden.

Außerdem bietet CVS die Möglichkeit, die Änderungen verschiedener Personen auf konsistente Weise zusammenzuführen.

Wie funktioniert CVS?

Zur Benutzung von CVS verwendet man den Befehl cvs. Im Regelfall benutzt man CVS, indem man ein Kommando mit dem Befehl übergibt (z.B. cvs init). Manchmal muss man noch einen oder mehrere zusätzliche Parameter angeben.

In diesem Tutorial werden wir folgende Befehlsaufrufe kennenlernen:

CVS funktioniert im Client/Server-Betrieb. Die zu verwaltenden Dateien werden von einem Serverprogramm betreut. Die Benutzer kommunizieren mit Server über ein Client-Programm (eben das Programm cvs). Mit diesem Programm können alle Schritte ausgeführt werden, die für das Arbeiten mit den Dateien notwendig sind. Das tolle daran ist nun, dass Server und Client auf verschiedenen Rechner laufen können.

Was muss ich tun, um CVS benutzen zu können?

Eines der wichtigsten Dinge beim Umgang mit CVS ist, dass man ihm mitteilt, wie es auf das CVS Repository zugreifen soll und wo es überhaupt zu finden ist. Zu diesem Zweck existiert die Umgebungsvariable CVSROOT die innerhalb der Konsole, mit der man/frau gerade arbeitet, gesetzt sein muss.

Umgebungsvariablen werden in der UN*X-Welt weithin benutzt und dienen dazu, den verschiedenen Programmen bestimmte Einstellungen beim ihrem Ablauf vorzugeben. Aber auch in der DOS/Windows-Welt werden Umgebungsvariablen benutzt. Die bekannteste Umgebungsvariable überhaupt dürfte wohl PATH sein.

Desweiteren muss sichergestellt sein, dass die/der BenutzerIn auf das Repository zugreifen darf, dass alle notwendigen Rechte vorhanden sind.

Um CVS benutzen zu können folgt man dem hier angegebenen 3-Punkte-Plan:

Die Variable CVSROOT dient dem Clientprogramm cvs dazu, mit dem Server zu kommunizieren. Die Variable hat folgenden Aufbau:

<Zugriffsmethode>:<Benutzername und Rechnername>:<Verzeichnis>

• <Zugriffsmethode> legt fest, wie der Client mit dem Server kommunizieren soll. Folgende Werte sind erlaubt:

  :ext	Kommunikation über Remote Shell
  :pserver	Kommunikation über ein CVS-eigenes Protokoll
  	Liegt das Repository auf dem gleichen Rechner wie das lokale Verzeichnis, oder ist das Repository über NFS zugreifbar, so bleibt dieses Feld leer.

• <Benutzername und Rechnername> Legt den Benutzernamen fest, mit dem sich der CVS-Client beim Server anmeldet und gibt an, auf welchem Rechner der Server läuft. Dieses Feld hat die Form

  benutzer@rechner

  Wenn man lokal arbeitet (d.h., die Zugriffsmethode ist leer), lässt man den Rechnernamen weg. Den Benutzernamen kann man ebenfalls weglassen. Es wird dann angenommen, dass man als die/derjenige BenutzerIn CVS nutzt, als die/der man eingeloggt ist.

• <Verzeichnis> Dies legt das Wurzelverzeichnis fest, in dem der Server die die Repositories verwaltet. Diese Angabe muss immer gemacht werden.

Und hier ein paar Beispiele:

CVSROOT=:ext:dau@meinrechner.bsp:/home/cvs

CVS benutzt die Remote-Shell für Zugriffe auf das Repository, das auf dem Rechner meinrechner.bsp liegt, und gibt sich gegenüber dem Server als Benutzer dau aus. Auf dem Rechner meinrechner.bsp liegt das Repository in dem Verzeichnis /home/cvs.

CVSROOT=dau:/home/cvs

Wie oben, nur liegt das Repository nun auf dem gleichen Rechner auf dem die CVS-BenutzerIn gerade arbeitet. Sie will als BenutzerIn dau auf das Repository zugreifen.

CVSROOT=/home/cvs

Wie oben, nur liegt das Repository nun auf dem gleichen Rechner auf dem die CVS-BenutzerIn gerade arbeitet. Sie will als diejenige BenutzerIn auf das Repository zugreifen, als die sie gerade eingeloggt ist.

Ein Anmerkung zum Schluss: das Setzen einer Umgebungsvariable ist von System zu System unterschiedlich. Unter UN*X sind zwei Varianten gebräuchlich:

CVSROOT=:ext:dau@meinrechner.bsp:/home/cvs

export CVSROOT

setenv CVSROOT :ext:dau@meinrechner.bsp:/home/cvs

Dieser Punkt entfällt, wenn man lokal auf dem Repository arbeitet. Hat man die Zugriffsmethode leer gelassen, kann man beruhigt bei Punkt 3 weiterlesen.

Damit man über eine entfernte Einwahl (Zugriffsmethode ext, siehe Variable CVSROOT) ohne Probleme mit dem Server kommunizieren kann, ist es notwendig, dass man sich ohne Angabe eines Kennwortes auf dem entfernten Rechner einloggen kann. Unter UN*X muss einE BenutzerIn hierzu in der Regel die Datei $HOME/.rhost entsprechend anpassen, sodass er/sie sich von dem Rechner aus, auf dem das Clientprogramm benutzt wird, auf dem Rechner einwählen kann, auf dem der CVS-Server läuft.

Damit man Daten in dem Repository verändern kann, muss man entsprechende Rechte in dem CVS-Verzeichnis besitzen (und zwar als die/derjenige, als der/die er/sie sich mit der Variablen CVSROOT beim Server ausgibt).

Zu diesem Zweck kann man das CVS-Wurzelverzeichnis (siehe Punkt 1) mit einer Gruppenkennung (beispielsweise cvsgroup) versehen und für diese Gruppe Schreibrechte in dem Verzeichnis vergeben. Alle Benutzer, die das CVS nutzen wollen, können dann dieser Gruppe zugeordnet werden. Dies geht natrlich nur, wenn man die Berechtigung zum Anlegen neuer Gruppen hat oder einen guten Draht zur AdministratorIn.

Mit diesem Punkt kommt man eher selten in Berührung (es sei denn, irgendwas funktioniert nicht), da es zumeist tatsächlich einE AdministratorIn gibt, die sich um diese Dinge kümmert. Meistens bekommt man nur mitgeteilt, als welcheR BenutzerIn man sich anmelden soll.

Wie kann ich ein neues Projekt erzeugen?

Bevor man CVS benutzen kann, muss das Repository vorbereitet werden. Hierzu benutzt man das Kommando

Nun ist CVS bereits bereit, Daten in das Repository aufzunehmen. Diesen Befehl sollte man nur einmal pro Projekt aufrufen. Normalerweise wird dies ohnehin die AdministratorIn tun.

Wie kann ich Daten in ein Projekt einfügen?

Das Einfügen von Daten geschieht normalerweise, indem man alle Dateien und Unterverzeichnisse eines Verzeichnisses als sogenanntes Modul in das Projekt einfügt.

Ein Modul ist dabei im Grunde genommen nichts anderes, als ein Unterverzeichnis innerhalb des Projektes. Die Arbeit mit Modulen ist insofern praktisch, als dass es sich beim Herausholen und Wiedereinstellen von Daten anbietet, dies immer mit ganzen Verzeichnissen zu tun.

Das Anlegen eines neuen Moduls/Projektverzeichnisses geschieht mit dem Kommando

cvs import [-m <Log-Eintrag>] <module> <vendor> <release>

Der Parameter module ist der Name des Moduls, in dem die Daten in dem Repository eingefügt werden. Später benutzt man diesen Namen zum Herausholen/Wiedereinstellen der Daten.

Der Parameter vendor ist eine beliebige Zeichenkette, die den/die Hersteller des Projektes kennzeichnen.

Der Parameter release ist eine beliebige Zeichenkette, die die Version kennzeichnet.

Lässt man den optionalen Parameter [-m <Log-Eintrag>] weg, so ruft CVS einen Editor auf, in dem man einen Log-Eintrag per Hand eintragen kann.

Hierzu ein Beispiel. Der Benutzer befindet sich in einem Verzeichnis, das den in CVS einzufügenden Datenbestand enthält. Die Daten sollen als CVS-Modul Testmodul eingefügt werden. Dazu ruft man den Befehl

cvs import -m "Neues Modul erzeugen" Testmodul dau start

auf. Achtung: es werden alle Dateien in dem aktuellen Verzeichnis, in dem man sich befindet, zu dem Projekt hinzugefügt.

Das geht einfach mit dem Befehl

cvs checkout <module>

Die Angabe <module> ist dabei ein Modul, das zuvor mit cvs import erzeugt wurde (siehe oben). Wurde beispielsweise ein Modul mit dem Aufruf

cvs import -m "Neues Modul erzeugen" Testmodul dau start

cvs checkout Testmodul

der komplette Verzeichniszweig des Moduls lokal erzeugt. Nach dem Aufruf wird man in dem aktuellen Verzeichnis ein Unterverzeichnis Testmodul/ vorfinden, in dem sich alle Dateien des Moduls befinden.

Man kann auch einzelne Dateien mit diesem Befehl aus dem Repository holen. Hierzu gibt man immer das vollständige Verzeichnis an. Also beispielsweise

Hierzu benutzt man das Kommando cvs commit. Normalerweise benutzt man foldenge Syntax:

Beispiele:

cvs commit -m "Datei blub.c geändert" blub.h	ändert die Datei blub.h
cvs commit -m "Modul bla geändert" bla	ändert das komplette Modul bla

Im Team kann es durchaus vorkommen, dass mehrere Personen an einzelnen Dateien gleichzeitig arbeiten. Geschieht dies, so kann es passieren, dass beim Zurückstellen von Dateien diese bereits in geänderter Fassung im Repository vorliegen. In diesem Falle versucht CVS zunächst die gemachten Änderungen zusammenzuführen. Erst wenn dies nicht geht, gibt CVS eine Fehlermeldung aus und bricht das commit ab.

Durch diese Vorgehensweise wird allerdings nicht der lokale Arbeitsbereich mit den Änderungen der anderen Teammitglieder versehen, sondern die Zusammenführung der Änderungen findet nur im zentralen Repository statt. Dies kann man erreichen, indem man nach dem commit direkt wieder ein checkout durchführt.

Will man jedoch "zwischendurch" die Änderungen anderer in den lokalen Arbeitsbereich übernehmen, so kann man die Abkürzung über das Kommando cvs update benutzen:

cvs update

Üblicherweise benutzt man update zusammen mit den Parametern -d und -P. Der Parameter -d bewirkt, dass auch neu hinzugekommene Unterverzeichnisse in dem lokalen Arbeitsbereich erstellt werden. Der Parameter -P bewirkt praktisch das Gegenteil, nälich, dass nicht mehr vorhandene Unterverzeichnisse auch aus dem lokalen Arbeitsbereich gelöscht werden.