Einführung in CVS - Praktische Informatik

Einführung in CVS
Udo Kelter
09.03.2003
Zusammenfassung dieses Lehrmoduls
Das Concurrent Versions System (CVS) ist eines der bekanntesten
und am meisten verbreiteten Konfigurationsmanagementsysteme. Dieses
Lehrmodul beschreibt zunächst die Architektur des Systems und
grundlegende Funktionsmerkmale, u.a. den konzeptuellen Aufbau eines
CVS-Repositories. Anhand eines Beispiels wird die Benutzung
der wichtigsten CVS-Operationen einführend dargestellt. Abschließend
werden einige Richtlinien angegeben, wie CVS benutzt werden
sollte.
Vorausgesetzte Lehrmodule:
obligatorisch: – Einführung in das Konfigurationsmanagement
Stoffumfang in Vorlesungsdoppelstunden: 1.0
1

Einführung in CVS 2
Inhaltsverzeichnis
1 Einleitung 3
2 Grobarchitektur 4
2.1 Verteilungsarchitektur . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Programm- und Bedienschnittstellen . . . . . . . . . . . . . . 5
2.3 Das Kommando cvs . . . . . . . . . . . . . . . . . . . . . . . 6
3 Das Repository 7
3.1 Konzeptioneller Inhalt eines Repositorys . . . . . . . . . . . . 7
3.2 Realisierung eines Repositorys . . . . . . . . . . . . . . . . . . 9
3.3 Bezeichnung eines Repositorys . . . . . . . . . . . . . . . . . 9
3.4 Übergabe der Repositorybezeichnung an cvs . . . . . . . . . 10
3.5 cvs login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4 Anlegen eines Repositorys 11
5 Anlegen von Arbeitsbereichen 13
6 Anlegen von Verzeichnissen und Dateien im Repository 14
7 Anlegen und Ändern von Dateien in einem Arbeitsbereich 16
7.1 checkout und commit . . . . . . . . . . . . . . . . . . . . . . 16
7.2 update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.3 Statusabfragen . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.4 remove . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8 Überwachung paralleler Änderungen 20
9 Benutzungsregeln 22
Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Glossar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
c○2003 Udo Kelter Stand: 09.03.2003
Dieser Text darf für nichtkommerzielle Nutzungen als Ganzes und unverändert in elektronischer oder
gedruckter Form beliebig weitergegeben werden und in WWW-Seiten, CDs und Datenbanken aufgenommen
werden. Jede andere Nutzung, insb. die Veränderung und Überführung in andere Formate, bedarf
der expliziten Genehmigung. Die jeweils aktuellste Version ist über http://kltr.de erreichbar.

Einführung in CVS 3
1 Einleitung
Das Concurrent Versions System (CVS) ist eines der bekanntesten
und verbreitetsten Konfigurationsmanagementsysteme (KMS).
Seinen Erfolg verdankt es mehreren Vorteilen gegenüber anderen KMS:
– Es ist als public-domain-Software frei verfügbar.
– Es ist für alle gängigen Plattformen erhältlich. Für die Bedienschnittstellen
sind plattformspezifische Varianten verfügbar, die an
das jeweilige look and feel der Plattform angepaßt sind.
– CVS unterstützt den lokalen und entfernten Zugriff auf ein Archiv.
Beim entfernten Zugriff werden diverse Protokolle und Verfahren
zum Einloggen auf den Server und Transfer der Daten unterstützt.
– CVS wurde und wird in sehr vielen Projekten eingesetzt und hat
sich in der Praxis in doppelter Hinsicht bewährt: Es läuft äußerst
stabil, und sein Funktionsumfang und die Auslegung der Basisfunktionalitäten
sind alltagstauglich.
Der Funktionsumfang von CVS deckt natürlich alle Grundfunktionalitäten
eines KMS ab. Hinzu kommen diverse Administrationsfunktionen.
Ein wichtiges Merkmal von CVS besteht darin, daß die Sperrung
von Dokumenten beim Checkout aus einem Archiv nicht direkt unterstützt
wird. In CVS ist die Strategie, ein Dokument beim Checkout
aus einem Archiv nicht zu sperren, eindeutig bevorzugt. Die Vor- und
Nachteile beider Strategien – zu sperren bzw. Varianten zuzulassen
und i.d.R. automatisch zu mischen –, sind in Abschnitt 2.6 in [KM]
schon diskutiert worden und sollen hier nicht wiederholt werden.
Einige graphische Front-ends für CVS bilden Sperren oberhalb der
Kernfunktionalität nach, wobei nicht immer klar ist, wie sicher solche
Implementierungen sind.
Intern benutzt CVS intensiv RCS (Revision Control System). Mit
RCS können Versionen einer Datei lokal verwaltet werden. Von RCS
stammen manche Meldungen, die bei der Benutzung von CVS ausgegeben
werden.
c○2003 Udo Kelter Stand: 09.03.2003

Einführung in CVS 4
2 Grobarchitektur
2.1 Verteilungsarchitektur
Bzgl. der Grobarchitektur muß unterschieden werden, ob das Versionsarchiv
(das Repository in der Begriffswelt von CVS) lokal, also
auf dem gleichen Dateisystem, auf dem auch der Entwickler arbeitet,
oder entfernt existiert 1 .
Bei einem lokalen Versionsarchiv können die von einem Entwickler
aufgerufenen CVS-Befehle direkt auf dem Archiv arbeiten.
Bei einem entfernten Versionsarchiv muß auf der Seite des Rechners,
der das Versionsarchiv enthält, ein Serverprozeß laufen, der über
Netzwerkverbindungen ansprechbar ist und die ihm übermittelte CVS-
Operation ausführt. Auf dem Rechner, an dem der Entwickler arbeitet,
muß ein Programm (das “CVS-Front-end”) verfügbar sein, das
mit dem Benutzer kommuniziert, die Verbindung zum Serverprozeß
herstellt und die Kommunikation mit dem Serverprozeß abwickelt, s.
Bild 1.
Arbeitsplatzrechner
Server
Entwickler
CVS-
Front-end
Repository
Arbeitsbereich
CVS-Server-
Prozeß
Abbildung 1: Front-end und CVS-Server
1 Bei verteilten Dateisystemen wie NFS können Dateisysteme, die in Wirklichkeit
auf einem Server gespeichert sind, bei anderen Rechnern – typischerweise Arbeitsplatzrechnern
– eingespiegelt werden. Auf den Arbeitsplatzrechnern bemerkt man
abgesehen von der Performance und einigen speziellen Details keinen Unterschied
zwischen lokal gehaltenen und eingespiegelten Dateisystemen. Ein Versionsarchiv,
das in einem eingespiegelten Dateisystem liegt, ist im Sinne von CVS daher ein lokal
vorhandenes Archiv, obwohl es nicht wirklich auf einer lokalen Platte gespeichert
ist.
c○2003 Udo Kelter Stand: 09.03.2003

Einführung in CVS 5
Bei einem entfernten Zugriff entstehen durch die Rechnerkommunikation
diverse Probleme bzgl. der Sicherheit und der Auswahl
der Kommunikationsprotokolle; auf diese Fragen gehen wir hier nicht
näher ein. Es dürfte nicht überraschen, daß das Einrichten eines entfernt
zugänglichen CVS-Repositorys kompliziert ist und Grundwissen
über Rechnernetzwerke erfordert.
Ein besonders positiver Aspekt von CVS ist, daß im normalen Betrieb,
sobald das Repository eingerichtet ist, praktisch kein Unterschied
zwischen einem lokalen und einem entfernten Archiv zu bemerken
ist.
2.2 Programm- und Bedienschnittstellen
CVS ist ein Datenverwaltungssystem in dem Sinne, daß es einen Datenbestand
– ein CVS-Repository – einkapselt 2 und nach außen hin
bestimmte Operationen exportiert, die auf diesem Datenbestand operieren.
Diese Operationen sind sowohl von Entwicklungswerkzeugen
(insb. Editoren) aus aufrufbar wie auch durch selbständige Programme,
die Entwicklern eine Bedienschnittstelle anbieten.
Das originäre CVS-System enthält “nur” eine Kommandozeilen-
Schnittstelle. Für Anfänger, deren Erfahrung mit Rechnern durch
Spiele oder Büropakete geprägt ist, sind solche Bedienschnittstellen
ungewohnt. Für professionellere Anwender sind Kommandozeilen-
Schnittstellen dagegen wichtiger als graphische Schnittstellen, da sie
oft effizienter bedient werden können und insb. weil man durch sie
CVS-Operationen innerhalb von Shell-Skripten aufrufen kann; Shell-
Skripten dienen meist zur Automatisierung umfangreicherer Arbeitsvorgänge.
Zusätzlich zur Kommandozeilen-Schnittstelle stehen diverse graphische
Bedienschnittstellen für CVS zur Verfügung. Diese basieren
teilweise direkt auf der Kommandozeilen-Schnittstelle, d.h. wenn z.B.
über ein Menü eine CVS-Operation aufgerufen wird und ggf. über ein
Formular Parameter erfaßt werden, dann wird aus diesen Angaben
2 Daß diese Kapselung nicht sicher ist und leicht durchbrochen werden kann, soll
uns hier nicht stören.
c○2003 Udo Kelter Stand: 09.03.2003

Einführung in CVS 6
letztlich eine Kommandozeile konstruiert und die Kommandozeilen-
Schnittstelle wird mit dieser Kommandozeile aufgerufen. Manche graphischen
Bedienschnittstellen zeigen diese Kommandozeile in einem
Protokollfeld auch direkt an. Die Historie mehrerer Operationsaufrufe
innerhalb einer Sitzung kann so gut überblickt werden, sofern man die
Kommandos versteht.
Die eigentlich interessante Leistung graphischer Front-ends besteht
eher in graphischen Darstellungen von Versionsabhängigkeiten oder
Differenzen zwischen Dateien und ggf. Editierfunktionen zum Zusammenmischen
von Varianten. Diese Funktionen sind bei den einzelnen
graphischen Front-ends recht verschieden ausgeprägt und stehen nicht
im Zentrum des Themas dieses Lehrmoduls; wir werden daher hier nur
die Kommandozeilen-Schnittstelle vorstellen.
2.3 Das Kommando cvs
In UNIX- bzw. Linux-Systemen besteht die gesamte Kommandozeilen-
Schnittstelle aus einem einzigen Programm namens cvs. Der erste
Stellungsparameter dieses Programms gibt die auszuführende CVS-
Operation an, z.B. checkout, die weiteren Parameter beziehen sich
dann auf die gewählte Operation. Insgesamt hat der Aufruf folgende
Form:
cvs [cvs-optionen 3 ] cvs-operation [cvs-op-optionen] {Parameter ... }
3 Als Option bezeichnet man i.d.R. Parameter, die einen Namen haben. Stellungsparameter
werden dagegen durch ihre Position in der Parameterliste identifiziert.
Man benutzt Optionen bei Parametern, für die normalerweise Vorgabewerte
ausreichen und die nur selten explizit gesetzt werden. In solchen Fällen wären Stellungsparameter
unpraktisch, weil die Parameterlisten extrem lang würden und bei
Aufrufen fast alle Positionen Leerwerte enthielten. Hierzu ein Beispiel: Das UNIX-
Kommando ls listet die Namen der Dateien im aktuellen Verzeichnis auf. Mit der
Option -l , also mit dem Aufruf ls -l , wird eine ausführliche Beschreibung jeder
Datei geliefert. Der Wertebereich dieses Parameters ist Boolean, Vorgabewert ist
false . Durch die Angabe von -l wird der Wert auf true gesetzt.
Bei den meisten Optionen ist der Wertebereich Boolean, es sind aber im Prinzip
beliebige Wertebereiche möglich, z.B. Texte oder Zahlen. In solchen Fällen wird der
gewünschte Wert hinter dem Optionsbezeichner als eigenes Wort in der Kommandozeile
angegeben. Beim Kommando ls kann z.B. die Breite der Ausgabe mit der
c○2003 Udo Kelter Stand: 09.03.2003

Einführung in CVS 7
Beispiele für CVS-Operationen sind login, checkout, edit, commit
, add und update; diese werden wir i.f. an Beispielen erläutern.
Der volle Funktionsumfang von CVS ist sehr komplex; wir
können hier nur einen Bruchteil davon vorstellen. Vollständige Beschreibungen
finden sich in der on-line-Dokumentation in Linux-Systemen
(Kommando: info cvs) sowie in [Ce01]. Ferner werden auf
http://www.cvshome.org/docs weitere Materialien angeboten.
3 Das Repository
3.1 Konzeptioneller Inhalt eines Repositorys
Konzeptionell enthält ein CVS-Repository einen Dateibaum, die
Blätter darin – i.f. als “Dateien” bezeichnet – sind Dokumente, die
i.a. in mehreren Versionen vorhanden sind. Verzeichnisse werden nicht
explizit versioniert.
Dateien haben Namen, wie in Dateisystemen üblich. Alle Versionen
einer Datei haben den gleichen Namen; Versionen einer Datei werden
durch eine Versionsnummer unterschieden. Die Versionsnummer ist
nicht Teil des Dateinamens.
In einem Arbeitsbereich eines Entwicklers liegen Kopien von einem
oder mehreren Teilbäumen des Repositorys. Die CVS-Operationen
arbeiten meist mit ganzen Teilbäumen, d.h. man braucht nicht jede
enthaltene Datei einzeln zu behandeln.
Der Arbeitsbereich enthält von jeder Datei i.d.R. nur eine Version,
die den gleichen Dateinamen wie im Repository hat. Es muß nicht
unbedingt die neuste Version sein. Man erkennt also am Dateinamen
nicht, um welche Version es sich handelt. CVS merkt sich in bestimmten
Hilfsdaten 4 , welche Version einer Datei im Arbeitsbereich vorliegt.
Option -w angegeben werden. Mit ls -w 40 werden die Ausgaben so formatiert,
daß sie in ein 40 Zeichen breites Fenster passen.
Eine ausführlichere Darstellung findet sich in [KSP].
4 Jeder Arbeitsbereich enthält ein Verzeichnis namens CVS , in dem diese Hilfsdaten
gespeichert werden. Dieses Verzeichnis darf nur durch cvs selbst verändert
werden.
c○2003 Udo Kelter Stand: 09.03.2003

Einführung in CVS 8
Numerierung von Versionen. CVS benutzt folgendes Schema zur
Numerierung von Versionen:
Beim Anlegen einer Datei erhält diese als erstes die Nummer 1.1.
Wenn eine neue Revision einer Datei angelegt wird, wird die hinterste
Ziffer um 1 hochgezählt. Nach 1.1 kommen also die Versionsnummern
1.2, 1.3, 1.4 usw.
Wenn von einer Datei mit Versionsnummer x.y eine erste Variante
angelegt wird, bekommt diese die Versionsnummer x.y.2.1. Die erste
Variante von Version 1.9 hat also die Nummer 1.9.2.1. Varianten existieren
bekanntlich parallel; wenn von unserer Variante neue Versionen
angelegt werden, gilt das oben Gesagte, d.h. es werden die Nummern
1.9.2.2, 1.9.2.3 usw. vergeben.
Man kann mehrere Varianten zu einer Version anlegen. Die zweite
Variante bekommt als Nummer x.y.4.1, in unserem Beispiel also
1.9.4.1, die dritte Variante 1.9.6.1 usw. Die ungeraden Ziffern werden
nicht benutzt, sondern für interne Zwecke verwendet.
Jede Variante kann unabhängig Revisionen bilden, es entstehen
so parallele Entwicklungszweige. Bild 2 zeigt ein Beispiel. Die horizontalen
Pfeile zeigen auf Nachfolge-Revisionen, die vertikalen auf
Varianten.
1.8 1.9 1.10 1.11
....
1.9.2.1 1.9.2.2 1.9.2.3 ....
1.9.4.1
1.9.4.2 ....
Abbildung 2: Beispiel eines Versionsgraphen
Eine gewisse Ungerechtigkeit liegt darin, daß die Varianten 1.9,
1.9.2.1, 1.9.4.1 usw. zwar im Prinzip alle gleichberechtigt sind, daß aber
die Ursprungsversion, die zuerst existierte, eine um 2 Stellen kürzere
Nummer hat. Daran kann man nichts ändern.
Man kann nach dem gleichen Schema auch noch Untervarianten bilc○2003
Udo Kelter Stand: 09.03.2003

Einführung in CVS 9
den, z.B. indem man von Version 1.9.2.2 die erste Variante 1.9.2.2.2.1
bildet.
3.2 Realisierung eines Repositorys
Ein Repository wird bei CVS durch ein Verzeichnis realisiert, das diverse
Dateien und Unterverzeichnisse enthält. Diese interne Struktur
interessiert uns jetzt nicht.
In diesem Verzeichnis legt cvs alle Versionen der Dokumente, die
sich unter Versionskontrolle befinden, und alle sonstigen, für interne
Zwecke benötigten Daten ab. Der Inhalt dieses Verzeichnisses sollte
allein durch cvs verändert werden.
Typischerweise unterscheiden sich aufeinanderfolgende Revisionen
eines Dokument nur an wenigen Stellen voneinander. So könnte z.B.
in einem Text von 100 Zeilen nur eine Zeile geändert oder eingefügt
worden sein. CVS (genauer gesagt das intern verwendete RCS) nutzt
diesen Sachverhalt intern zu einer Optimierung dahingehend aus, daß
nur die Differenzen der Dateien gespeichert werden und nicht jedesmal
der komplette Text.
3.3 Bezeichnung eines Repositorys
Auf einem Rechner und sogar in den Verzeichnissen eines einzelnen
Benutzers können beliebig viele CVS-Repositories angelegt werden.
Daher benötigt cvs eine Angabe, mit welchem Repository gearbeitet
werden soll.
Ein lokales Repository wird angegeben durch den absoluten Pfadnamen
des Repositoryverzeichnisses.
Bei einem entfernten Repository muß der Name des Rechners angegeben
werden, auf dem das Repository gespeichert ist, sowie der
absolute Pfadname des Repositoryverzeichnisses auf diesem entfernten
Rechner. Diese beiden Namen werden mit weiteren Angaben, die
wir anschließend bei der login-Operation erläutern werden, zu einer
einzigen Zeichenkette zusammengefaßt.
c○2003 Udo Kelter Stand: 09.03.2003

Einführung in CVS 10
3.4 Übergabe der Repositorybezeichnung an cvs
Da man meist nur mit einem bestimmten Repository arbeitet, wäre es
lästig, dieses bei jedem Aufruf angeben zu müssen. Stattdessen kann
das Repository in der Umgebungsvariablen 5 CVSROOT übergeben werden.
In der auf UNIX-Systemen verbreiteten c-Shell (csh) oder der
tc-Shell (tcsh) wäre folgendes Kommando einzugeben, um cvs anzuzeigen,
daß mit dem Repository im lokal vorhandenen Verzeichnis
/home/schmitz/pg/archiv gearbeitet werden soll:
setenv CVSROOT /home/schmitz/pg/archiv
In der ba-Shell (bash) ist folgendes einzugeben 6 :
export CVSROOT=/home/schmitz/pg/archiv
Das Repository kann aber auch beim Aufruf von cvs mittels der
Option -d angegeben werden:
cvs -d /home/schmitz/pg/archiv .....
3.5 cvs login
Bei einem entfernt zugreifbaren Repository könnten Unberechtigte versuchen,
auf das Repository zuzugreifen. Daher wird der Zugang nur
einzelnen Benutzern erlaubt, die sich durch ein Paßwort ausweisen
müssen. Hierzu dient die CVS-Operation cvs login; das Paßwort
muß interaktiv eingegeben werden, es wird intern aufbewahrt und anschließend
bei jedem Zugriff benutzt (auch über mehrere Rechnersitzungen
hinweg). Mit cvs logout kann das Paßwort wieder gelöscht
werden.
5 Umgebungsvariablen sind eine weitere Technik, mit der in UNIX-Betriebssystemen
Parameter von einem Prozeß an einen Kind-Prozeß übergeben werden können.
Eine Umgebungsvariable hat einen Namen und einen Wert. Ein Prozeß kann Umgebungsvariablen
erzeugen und ihren Wert setzen. Ein von diesem Prozeß gestartetes
Programm erbt die Umgebungsvariablen und kann deren Werte dann lesen.
6 Anstatt dieses Kommando bei jeder Sitzung erneut einzugeben ist es bequemer,
es in die Datei $HOME/.bashrc bzw. $HOME/.cshrc einzutragen; die Umgebungsvariable
ist dann automatisch in jeder Sitzung gesetzt.
Den gleichen Effekt erzielt man bei den meisten graphischen Front-ends, indem
man die Repositorybezeichnung in den Voreinstellungen einträgt.
c○2003 Udo Kelter Stand: 09.03.2003

Einführung in CVS 11
Der Benutzername, unter dem man sich einloggen möchte, wird in
einer erweiterten Form des Repository-Namens angegeben (man kann
geteilter Meinung sein, ob das besonders elegant ist). Dies gilt auch
für das Kommunikationsprotokoll, das zur Kommunikation zwischen
CVS-Front-end und CVS-Server verwendet werden soll. Z.B. bedeutet
der Wert
:pserver:karl@xyz.abc.de:/home/schmitz/pg/archiv
in CVSROOT, daß mittels des pserver-Protokolls 7 Verbindung mit dem
Rechner xyz.abc.de aufgenommen werden soll, und zwar für den dort
bekannten Benutzer karl.
4 Anlegen eines Repositorys
Ziel der folgende Abschnitte ist, die wichtigsten CVS-Operationen
an Beispielen zu erklären. Die einzelnen dabei benutzten CVS-
Operationen werden nicht im Detail erklärt - hierzu sei auf [Ce01] und
die on-line-Dokumentation verwiesen. Das Ziel ist vielmehr, einen ersten
Überblick zu geben und das Zusammenspiel der CVS-Operationen
klarzumachen.
Es ist sinnvoll, die gezeigten Beispiele an einem Rechner praktisch
nachzuvollziehen 8 . Hierzu benötigt man ein installiertes Repository.
Erst nachdem ein Repository vorhanden ist, können Arbeitsbereiche
eingerichtet werden (mit Hilfe der Operation checkout).
Das Einrichten eines verteilt zugreifbaren Repositorys ist kompliziert
und kein Lernziel dieses Lehrmoduls. Sofern kein zentrales vorkonfektioniertes
Repository verfügbar ist oder man auf einem nicht
vernetzten Rechner üben will, muß mit einem lokalen Repository gearbeitet
werden. Nachfolgend zeigen wir an einem Beispiel, wie ein
Repository lokal initialisiert werden kann. Die Kommandos unterstellen
die bash als Kommandointerpreter.
7 Es gibt weitere Protokolle, die wir hier aber nicht betrachten.
8 Über die WWW-Seite zu diesem Lehrmodul ist ein Shell-Skript erhältlich, das
eine Sequenz von Kommandos mit Erläuterungen durchführt.
c○2003 Udo Kelter Stand: 09.03.2003

Einführung in CVS 12
1. Erzeugen eines leeren Repositorys. Im Beispiel legen wir das
Repository im home-Verzeichnis unter dem Namen archiv an:
export CVSROOT=$HOME/archiv
cvs init
Die CVS-Operation init erzeugt im angegebenen Verzeichnis ein leeres
Repository.
2. Anlegen einer initialen Verzeichnisstruktur im Repository.
Angenommen, wir wollen die Programmquelltexte in einem Verzeichnis
src speichern, die Dokumentation in einem Verzeichnis docs,
darin zwei Unterverzeichnisse docs/handbuch und docs/install für
das Benutzerhandbuch und die Installationsanweisungen. Wir legen
zunächst an einer beliebigen Stelle im Dateisystem ein Hilfsverzeichnis
initdirs an und erzeugen dort die gewünschten Verzeichnisse:
mkdir initdirs
mkdir initdirs/docs
mkdir initdirs/docs/handbuch
mkdir initdirs/docs/install
mkdir initdirs/src
Diese Struktur können wir nun mit Hilfe der CVS-Operation import
in das Repository übernehmen. Dies überträgt die Inhalte des Verzeichnisses,
in dem sie aufgerufen wird, in das Repository. Wir müssen
also zunächst in unser Hilfsverzeichnis initdirs hineinnavigieren:
cd initdirs
cvs import -m "initiale Verzeichnisstruktur erzeugt" \
ws2003/propra x y
Der Schrägstrich am Ende einer Zeile bedeutet, daß das begonnene
Kommando in der Folgezeile fortgesetzt wird.
Die Option -m ... (m wie message) erlaubt es, einen Kommentar
zu hinterlegen.
Der erste Stellungsparameter ws2003/propra gibt ein Unterverzeichnis
innerhalb des Repositorys an, in dem die Verzeichnisstruktur
c○2003 Udo Kelter Stand: 09.03.2003

Einführung in CVS 13
erzeugt werden soll; sofern noch nicht vorhanden, werden diese Verzeichnisse
im Repository erzeugt. Auf diese Weise ist es möglich, für
mehrere Arbeitsbereiche, die für unterschiedliche parallele Aktivitäten
nötig sein mögen, mit einem einzigen Repository auszukommen.
Die beiden folgenden Stellungsparameter (x und y ) dürfen nicht
fehlen, sind aber im Moment uninteressant.
Man beachte, daß beim bisherigen Stand der Dinge unser Hilfsverzeichnis
initdirs nicht automatisch zu einem Arbeitsbereich geworden
ist. Es wird nicht weiter benötigt und kann gelöscht werden.
5 Anlegen von Arbeitsbereichen
Zu einem Repository können bekanntlich mehrere Arbeitsbereiche
angelegt werden. In unserem Beispiel wollen wir im Verzeichnis
$HOME/arbeit zwei Arbeitsbereiche ab1 und ab2 anlegen. Normalerweise
gehören Arbeitsbereiche zu verschiedenen Entwicklern. Um das
Beispiel einfacher nachvollziehbar zu machen, führen wir hier alle Operationen
unter einem einzigen Benutzer aus. Die CVS-Operationen
könnten aber ebensogut in jedem Arbeitsbereich von einem anderen
Entwickler durchgeführt werden. Wir legen zunächst entsprechende
leere Verzeichnisse an:
mkdir $HOME/arbeit
mkdir $HOME/arbeit/ab1
mkdir $HOME/arbeit/ab2
Anlegen können wir einen Arbeitsbereich mit der CVS-Operation
checkout (abgekürzt co ). Als impliziten Parameter hat auch diese
das Verzeichnis, in dem sie aufgerufen wird: in diesem Verzeichnis
werden die CVS-Dateien für einen Arbeitsbereich angelegt oder, sofern
schon vorhanden, korrigiert. Wir müssen also in unseren ersten
Arbeitsbereich wechseln:
cd $HOME/arbeit/ab1
cvs checkout -d . ws2003/propra
c○2003 Udo Kelter Stand: 09.03.2003

Einführung in CVS 14
Der Parameter ws2003/propra bezeichnet den Teilbaum des Repositorys,
der hierhin kopiert werden soll. Ohne die Option -d . würden
die vollen Pfadnamen des Repositorys auch im Dateisystem erzeugt,
also z.B. das Verzeichnis
$HOME/arbeit/ab1/ws2003/propra/docs/handbuch
Die Option -d . bewirkt, daß nur die “lokalen” Pfadnamen von
ws2003/propra aus erzeugt werden. Statt des vorstehenden Verzeichnisses
entsteht somit:
$HOME/arbeit/ab1/docs/handbuch
6 Anlegen von Verzeichnissen und Dateien im
Repository
Anlegen vn Textdateien Angenommen, wir wollen nun im Verzeichnis
docs/handbuch die Datei hb.txt erstellen und unter Versionskontrolle
nehmen. Hierzu benutzt man die CVS-Operationen add
und commit. add merkt eine Datei nur zur Eintragung in das Repository
vor, eingetragen wird die Datei erst nach dem commit. Beide
Kommandos müssen im jeweils betroffenen Verzeichnis ausgeführt
werden; wir navigieren also in unserem Beispiel zunächst dorthin:
cd docs/handbuch
echo ’aller Anfang ist schwer’ > hb.txt
cvs add hb.txt
cvs commit -m ’die erste Zeile’ hb.txt
Beim commit-Kommando kann man i.d.R. auf die Angabe der Datei
verzichten. Ist keine Datei angegeben, durchsucht CVS das aktuelle
Arbeitsverzeichnis und dessen Unterverzeichnisse nach Dateien,
die zur Eintragung in das Repository vorgemerkt sind, und führt alle
Eintragungen durch.
Binärdateien. Unter Binärdateien verstehen wir Dateien, in denen
nicht darstellbare Byteinhalte vorkommen. Beispiele sind die gängigen
Formate für Bilder, Spreadsheets und mit gzip komprimierte Dateien.
c○2003 Udo Kelter Stand: 09.03.2003

Einführung in CVS 15
Wir hatten bisher unterstellt, daß Dateiinhalte bei einem commit
völlig unverändert in das Repository übertragen werden. Dies ist nicht
völlig korrekt, in Wirklichkeit werden bestimmte kleinere Veränderungen
vorgenommen. Eine der Veränderungen besteht darin, die Zeilenendemarkierungen
in den Dateien zu vereinheitlichen. Hierzu ist
anzumerken, daß die Zeilenendemarkierungen in den unterschiedlichen
Betriebssystemen nicht einheitlich gehandhabt werden. Würde ein Repository
von mehreren Rechnern mit verschiedenen Betriebssystemen
aus benutzt, ohne die Zeilenendemarkierungen zu vereinheitlichen, so
würden die Algorithmen zur Bildung der Differenzen zwischen Revisionen
in jeder Zeile eine Änderungen feststellen und nicht mehr sinnvoll
arbeiten.
In Binärdateien können zufällig auch Folgen von Byteinhalten
auftreten, die identisch mit einer Zeilenendemarkierung sind, aber
natürlich keine solche darstellen. Diese Byteinhalte dürfen offensichtlich
nicht gegen eine andere Darstellung eines Zeilenendes ausgetauscht
werden, hierdurch würde der Dateiinhalt unbrauchbar werden. Durch
die Option -kb in der CVS-Operation add kann erzwungen werden,
daß eine Datei völlig unverändert übernommen wird. Wenn wir beispielsweise
von irgendwoher die Bilddatei logo.gif in unseren Arbeitsbereich
kopiert hätten, würden wir dieses Bild wie folgt in das
Repository übernehmen:
cvs add -kb logo.gif
cvs commit -m ’neues Bild’ logo.gif
Anlegen von Verzeichnissen. Im Gegensatz zu Dateien werden
(Unter-) Verzeichnisses von add sofort im Repository eingetragen.
Nach
mkdir glossar
cvs add -m ’ Verzeichnis glossar erzeugt’ glossar
befindet sich also das Verzeichnis docs/handbuch/glossar sofort im
Repository (und nicht erst nach dem nächsten commit).
c○2003 Udo Kelter Stand: 09.03.2003

Einführung in CVS 16
7 Anlegen und Ändern von Dateien in einem
Arbeitsbereich
7.1 checkout und commit
Das Neuanlegen von Dateien oder Verzeichnissen im Repository ist
eher die Ausnahme. Meist werden Dateien, die schon im Repository
vorhanden sind, modifiziert. Hierzu werden sie mit der CVS-Operation
checkout in den Arbeitsbereich kopiert. Nach Beendigung der Änderung
wird die neue Version mit commit wieder in das Repository übernommen.
In unserem Beispiel wechseln wir in den zweiten Arbeitsbereich und
erzeugen dort eine Kopie des kompletten Teilbaums, den wir eben im
ersten Arbeitsbereich angelegt haben.
cd $HOME/arbeit/ab2
cvs checkout -d . ws2003/propra
Wir finden anschließend in $HOME/arbeit/ab2/docs/handbuch unsere
Datei hb.txt. Wir navigieren jetzt in dieses Verzeichnis, hängen
eine Zeile an die Datei an und führen danach wieder ein commit aus:
cd docs/handbuch
echo ’nun ja’ >> hb.txt
cvs commit -m ’die zweite Zeile’ hb.txt
CVS meldet uns dann, daß Revision 1.2 von hb.txt eingetragen worden
ist.
Um des Beispiels willen erzeugen wir jetzt noch eine weitere Datei
und tragen sie mit add und commit im Repository ein:
echo ’noch ein Text’ > nochn.txt
cvs add nochn.txt
cvs commit nochn.txt
“Originaldateien”. Da wir jetzt mit der Arbeit an hb.txt fertig
sind und der neue Stand im Repository eingetragen ist, können wir,
c○2003 Udo Kelter Stand: 09.03.2003

Einführung in CVS 17
wenn wir wollen, hb.txt ohne weiteres löschen, denn wir können sie
ja bei Bedarf wieder mit einem checkout restaurieren. In der Praxis
wird man dies i.a. nicht tun, das Beispiel soll vielmehr folgendes
klarmachen: Die übliche Denkweise, wonach man seine “Originale” in
seinen Arbeitsverzeichnissen hat und ggf. an anderer Stelle eine Sicherungskopie,
wird bei der Benutzung eines Repositorys sozusagen
umgekehrt: die “Originale” befinden sich im Repository, die Arbeitsbereiche
enthalten nur Kopien, die modifiziert sein können. Daher
wird eine Datei in einem Arbeitsbereich, die eine korrespondierende
Datei im Repository hat, oft als Kopie bezeichnet.
7.2 update
Wir haben nun in unseren beiden Arbeitsbereichen Kopien der gleichen
Dateien aus dem Repository vorliegen, wobei im Arbeitsbereich
ab1 eine Datei fehlt und eine einen veralteten Stand hat. Aus Sicht des
Arbeitsbereichs ab1 entspricht dies der Situation, daß jemand anders
die Dokumente inzwischen weiterentwickelt hat und daß die Änderungen
lokal nachvollzogen werden müssen. Hierzu ist die CVS-Operation
update verfügbar.
Bei einem Aufruf von update können Dateien oder Verzeichnisse
angegeben werden, die auf den neuesten Stand gebracht werden sollen.
Bei Verzeichnissen werden das Verzeichnis und alle direkten und indirekten
Unterverzeichnisse durchlaufen und alle gefundenen Dateien
behandelt. Sofern die im Arbeitsbereich befindliche Kopie identisch
mit der neusten Revision im Repository ist, passiert nichts. Andernfalls
wird eine Korrektur erforderlich, wobei verschiedene Fälle zu unterscheiden
sind. Bezüglich des Zustands der Datei im Arbeitsbereich
sind folgende Fälle von Interesse:
(A) die Datei existiert noch nicht oder nicht mehr im Arbeitsbereich
(B) Die Datei existiert im Arbeitsbereich und entsprach bei ihrem
checkout oder dem letzten update oder commit der Revision
X. Seit diesem Zeitpunkt können sowohl im Arbeitsbereich als
auch im Repository Veränderungen eingetreten sein. Folgende
Fälle sind denkbar:
c○2003 Udo Kelter Stand: 09.03.2003

Einführung in CVS 18
(1) die Datei im Arbeitsbereich ist unverändert.
(2) die Datei im Arbeitsbereich wurde verändert.
(a) Revision X ist die letzte im Repository.
(b) Revision X ist nicht mehr die letzte im Repository.
Insg. ergeben sich 4 Kombinationen B1a, B1b, B2a und B2b.
CVS reagiert auf diese Fälle wie in der folgenden Tabelle angegeben.
Im Fall (B1a) passiert nichts; in den anderen Fällen gibt update einen
Kennbuchstaben und den Dateinamen aus.
Fall Reaktion Kennbuchstabe
(A) Datei wird neu erzeugt U
(B1a) keine Änderung -
(B1b) Datei wird auf den gleichen Stand wie das U
Repository gebracht
(B2a) keine Änderung M
(B2b) automatische Mischung der Änderungen;
hierbei traten ...
... keine Mischkonflikte auf M
... Mischkonflikte auf C
Darüber hinaus existieren u.a. die folgenden Meldungen:
A Die Datei wurde im Arbeitsbereich angelegt, muß aber noch mit
commit gesichert werden.
R Die Datei wurde im Arbeitsbereich gelöscht, die Löschung muß
aber noch mit commit im Repository nachvollzogen werden.
In unserem Beispiel ändern wir zunächst die Datei hb.txt ab
und provozieren so einen Mischkonflikt. Danach veranlassen wir ein
update für das komplette Verzeichnis docs:
cd $HOME/ab1
echo ’nur Mut!’ >> docs/handbuch/hb.txt
cvs update docs
c○2003 Udo Kelter Stand: 09.03.2003

Einführung in CVS 19
update legt die Datei nochn.txt neu an und mischt die Änderungen
in hb.txt; hierbei wird eine Warnung ausgegeben – auf solche
Warnungen ist zu achten! – und die ursprünglich im Arbeitsbereich
vorhandene Datei unter einem anderen Namen verwahrt. hb.txt hat
anschließend folgenden Inhalt:
aller Anfang ist schwer
> 1.2
Oberhalb der Zeile ======= steht der bisher im Arbeitsbereich
vorhandene Text, darunter der Text gemäß der letzten Version im Repository.
Option -D. Normalerweise zieht update alle Änderungen nach, die
seit dem Anlegen der Dateien im Arbeitsbereich (bzw. seit dem letzten
Update) im Repository eingetragen wurden. Dies geht manchmal zu
weit. So kann an einem bestimmten Datum ein konsistenter Zustand
vorhanden gewesen sein, seitdem kann aufgrund nicht abgeschlossener
Arbeiten ein inkonsistenter Zwischenzustand im Repository eingetragen
sein, den nicht jeder sehen möchte. In solchen Fällen kann durch
die Option -D datum bewirkt werden, daß nur die Änderungen bis zu
diesem Datum nachvollzogen werden.
7.3 Statusabfragen
Daß unsere Datei hb.txt Revision 1.2 ist, kann man ihr am Dateinamen
nicht ansehen. Die Versionsnummer und diverse andere Angaben
zum Zustand von Dateien im Arbeitsbereich kann man mit der CVS-
Operation status abfragen. Beispiel:
cvs status hb.txt
c○2003 Udo Kelter Stand: 09.03.2003

Einführung in CVS 20
7.4 remove
Es kann natürlich auch der Fall eintreten, daß wir eine Datei komplett
löschen wollen. Es reicht jetzt nicht mehr aus, die Datei einfach
im Arbeitsbereich zu löschen, das nächste cvs update würde sie
wiederherstellen. Stattdessen muß sie explizit im Repository gelöscht
werden. Hierzu dient die CVS-Operation remove: sie merkt vor, daß
die angegebenen Dateien oder Verzeichnisse beim nächsten commit im
Repository gelöscht werden sollen. Vor dem cvs remove müssen die
Dateien im Arbeitsbereich gelöscht worden sein. Hierzu ein Beispiel
(wir unterstellen, daß die Datei versuch1.java vorher mit add und
commit im Repository eingetragen worden ist):
rm versuch1.java
cvs remove versuch1.java
cvs commit versuch1.java
8 Überwachung paralleler Änderungen
Obwohl CVS Sperren nicht direkt unterstützt, bietet es Mechanismen
an, durch die bei entsprechender Disziplin der Entwickler verhindert
werden kann, daß mehrere Entwickler die gleiche Datei editieren.
Die Überwachung paralleler Änderungen kann für einzelne Dateibäume
des Repositorys ein- und ausgeschaltet werden. Hierzu dient
die CVS-Operation watch
cvs watch on [-l] [-R] dateien ....
Diese CVS-Operation schaltet die Überwachung für die angegebenen
Dateien und Verzeichnisse ein. Wenn ein Verzeichnis angegeben wird,
wird dort überwacht, ob neue Dateien angelegt werden; für die neuen
Dateien wird die Überwachung automatisch eingeschaltet. Normalerweise
arbeitet watch rekursiv, wenn also ein Verzeichnis angegeben
wird, auch auf allen direkt oder indirekt enthaltenen Verzeichnissen
und Dateien. Das rekursive Arbeiten kann durch die Option -l (l wie
lokal) abgeschaltet werden. CVS kann aber auch so konfiguriert werc○2003
Udo Kelter Stand: 09.03.2003

Einführung in CVS 21
den, daß das lokale Arbeiten voreingestellt ist; in diesem Fall bewirkt
die Option -R , daß rekursiv gearbeitet wird.
Abgeschaltet werden kann die Überwachung durch
cvs watch off [-l] [-R] dateien ....
Die Optionen und Parameter werden hier genauso behandelt wie bei
watch on.
Die Überwachung ändert die Wirkung des checkout: während
dieses bisher Dateien im Arbeitsbereich mit Lese- und Schreibrechten
anlegte, werden nun nur noch Leserechte eingeräumt.
Wenn ein Entwickler nun eine Datei verändern möchte, muß er
vorher eine weitere CVS-Operation aufrufen: edit 9 . Beispiel:
cvs edit hb.txt ...
Diese Operation hat folgende Effekte:
– Alle Entwickler, die die angegebene Datei überwachen, werden von
der geplanten Änderung informiert. Das CVS-System ist so konfigurierbar,
daß den betroffenen Benutzern eine elektronische Nachricht
geschickt wird (dies ist allerdings nicht voreingestellt).
– Der Benutzer, der cvs edit aufgerufen hat, wird ab sofort von
Änderungen anderer Entwickler an der Datei informiert.
– Es werden Schreibrechte an den Dateien eingeräumt.
Die Datei kann nunmehr verändert werden, und der neue Stand
kann wie üblich mit commit in das Repository übertragen werden.
Das commit zeigt das Ende der Bearbeitung an, daher werden als Seiteneffekt
die Schreibrechte wieder entfernt, ferner wird der Entwickler
von Änderungen anderer Entwickler an der Datei nicht mehr benachrichtigt,
Sofern aus irgendeinem Grund die Bearbeitung der Datei ohne
commit abgebrochen werden muß, ist die CVS-Operation unedit zu
benutzen. Diese hat folgende Effekte:
9 Man kann natürlich auch die Rechte direkt im Dateisystem ändern und die
CVS-Mechanismen so unterlaufen, d.h. die CVS-Mechanismen sind in dieser Hinsicht
nicht sicher.
c○2003 Udo Kelter Stand: 09.03.2003

Einführung in CVS 22
– Die angegebenen Dateien werden auf den Zustand zurückgesetzt,
den sie beim letzten commit, update bzw. checkout hatten.
– Die Benachrichtigung über Änderungen anderer Entwickler an der
Datei wird aufgehoben.
– Die Schreibrechte an den Dateien werden wieder entzogen.
9 Benutzungsregeln
In den bisherigen Abschnitten wurden die wichtigsten Funktionen von
CVS eingeführt, wobei offen blieb, wie sie sinnvoll und systematisch
eingesetzt werden sollten. Als Abschluß folgen daher einige Benutzungsregeln:
1. Man sollte so oft wie möglich die Dateien in einem privaten Arbeitsbereich
mit update auf den neuesten Stand bringen. Dies gilt
besonders für Dokumente, die bisher noch unverändert sind und
jetzt bearbeitet werden sollen; sie könnten seit dem checkout von
jemand anderem verändert worden sein.
2. Es sollten nur compilierfähige Programme bzw. allgemeiner gesagt
hinreichend konsistente Dokumente in das Repository eingetragen
werden. Der notwendige Grad an Konsistenz hängt vom Dokumenttyp
und ggf. vom Arbeitsstil einer Gruppe ab. Jedenfalls muß nach
einer Eintragung immer damit gerechnet werden, daß ein anderes
Gruppenmitglied diese Revision als Basis eigener Arbeiten benutzt.
3. Neue Zustände von Dokumenten sollten möglichst früh in das Repository
eingetragen werden.
Dies sieht auf den ersten Blick wie ein Widerspruch zur vorherigen
Regel aus, ist es aber nicht. Beide Regeln zusammen bedeuten,
daß man umfangreichere Änderungen möglichst in eine Folge kleinerer
Änderungen aufteilt, die jeweils zu einem konsistenten Zwischenzustand
führen. Dahinter steckt die ganz generelle Lebensweisheit,
nicht parallel an vielen Problemen herumzubasteln, sondern
sich auf wenige Dinge zu konzentrieren und diese zügig zum
Abschluß zu bringen.
c○2003 Udo Kelter Stand: 09.03.2003

Einführung in CVS 23
4. Arbeitsgruppen, die noch wenig Erfahrung in Teamarbeit haben
– hierzu zählen insbesondere Gruppen in Programmierpraktika
und studentische Projektgruppen – sollten systematisch edit und
unedit einsetzten, um unkontrollierte Parallelarbeit am gleichen
Dokument zu verhindern. Der Mehraufwand zum Aufruf dieser
CVS-Operationen ist vergleichsweise gering, während die Behebung
inkompatibler Änderungen viel Zeit kosten und Ärger verursachen
kann.
5. CVS macht Planung und Kommunikation in der Gruppe nicht überflüssig.
Wenn es häufig dazu kommt, daß verschiedene Entwickler
das gleiche Dokument bearbeiten und vielleicht sogar Mischkonflikte
auftreten, kann eine schlechte Modularisierung des Systems
und eine ungeschickte Arbeitsaufteilung die Ursache sein; ein KMS
macht solche Planungsfehler nur sichtbar, beheben kann es sie nicht.
Literatur
[Ce01] Cederqvist, Per: Version management with CVS (v1.11.1p1);
2001 (in verschiedenen Formaten auf http://www.cvshome.-
org/docs/ erhältlich)
[Ti85] Tichy, Walter F.: RCS - a system for version control; Software
- Practice & Experience 15:7, p.637-654; 1985/07
[KM] Kelter, U.: Lehrmodul “Einführung in das Konfigurationsmanagement”;
2003
[KSP] Kelter, U.: Lehrmodul “Kommandosprachen und Shell-Programmierung”;
1988
Glossar
cvs add: CVS-Operation zum Anlegen neuer Dateien im Repository
cvs checkout: CVS-Operation zum Ausbuchen von Dateien
cvs commit: CVS-Operation zum Bestätigen von Änderungen
cvs edit: CVS-Operation, mit der man ankündigen kann, daß eine Datei
editiert werden soll
c○2003 Udo Kelter Stand: 09.03.2003

Einführung in CVS 24
cvs remove: CVS-Operation zum Löschen von Dateien im Repository
cvs status: CVS-Operation zur Anzeige des Zustands von Dateien in einem
Arbeitsbereich
cvs update: CVS-Operation, mit der Dateien, die sich im Arbeitsbereich
befinden, auf den neuesten Stand gemäß Repository gebracht werden
können; eine Variante von update erlaubt es, Varianten von Dateien
zu mischen
cvs watch: CVS-Operation, mit der die Überwachung von Dateien und Verzeichnissen
ein- und ausgeschaltet werden kann
CVSROOT: Umgebungsvariable, die den Namen des von cvs zu benutzenden
Repositorys enthält
Repository (im Kontext von CVS): Synonym zu Versionsarchiv; technisch
gesehen der Name eines Verzeichnisses
c○2003 Udo Kelter Stand: 09.03.2003

Index
Arbeitsbereich, 13
Arbeitsplanung, 23
Archiv, siehe Repository
Benachrichtigung, 20
Binärdateien, 14
Concurrent Versions System, 3
CVS, 3
Arbeitsbereich, 11
Benutzungsregeln, 22
Front-end, 3–5
graphisches, 5
Kommandozeilen-Schnittstelle, 5
cvs, 6
add, 14, 16, 23
checkout, 13, 16, 21, 23
co, 13
commit, 14–16, 21, 23
CVSROOT, 10
edit, 21–23
import, 12
init, 11
login, 10
logout, 10
remove, 20, 23
Repositorybezeichnung, 10
status, 19, 24
unedit, 21
update, 17, 19, 22, 24
Kennbuchstaben, 18
watch, 20, 24
CVSROOT, 24
Konfigurationsmanagement
∼system, 3
Kooperation, 22
Kopie, 17
Mischkonflikt, 18, 23
Darstellung, 19
Option, 6
parallele Änderungen, 20
RCS, 3, 9
Repository, 4, 24
Aktualisierung, 17
Anlegen, 11
Anlegen von Dateien, 14
Anlegen von Verzeichnissen, 15
Bezeichnung, 9
entfernter Zugriff, 3, 4, 9
konzeptioneller Inhalt, 7
leeres, 11
Realisierung, 9
Revision, 8, 17
Sperre, 3, 20
Stellungsparameter, 6
Variante, 8
Versionsnummer, 7
Zeilenendemarkierung, 14
Differenzen, 6, 9
KMS, 3
25