Einf uhrung in CVS -...

Einfuhrung in CVS

Udo Kelter

09.03.2003

Zusammenfassung dieses Lehrmoduls

Das Concurrent Versions System (CVS) ist eines der bekanntestenund am meisten verbreiteten Konfigurationsmanagementsysteme. Die-ses Lehrmodul beschreibt zunachst die Architektur des Systems undgrundlegende Funktionsmerkmale, u.a. den konzeptuellen Aufbau ei-nes CVS-Repositories. Anhand eines Beispiels wird die Benutzungder wichtigsten CVS-Operationen einfuhrend dargestellt. Abschlie-ßend werden einige Richtlinien angegeben, wie CVS benutzt werdensollte.

Vorausgesetzte Lehrmodule:

obligatorisch: – Einfuhrung in das Konfigurationsmanagement

Stoffumfang in Vorlesungsdoppelstunden: 1.0

1

Einfuhrung in CVS 2

Inhaltsverzeichnis

1 Einleitung 3

2 Grobarchitektur 42.1 Verteilungsarchitektur . . . . . . . . . . . . . . . . . . . . . . 42.2 Programm- und Bedienschnittstellen . . . . . . . . . . . . . . 52.3 Das Kommando cvs . . . . . . . . . . . . . . . . . . . . . . . 6

3 Das Repository 73.1 Konzeptioneller Inhalt eines Repositorys . . . . . . . . . . . . 73.2 Realisierung eines Repositorys . . . . . . . . . . . . . . . . . . 93.3 Bezeichnung eines Repositorys . . . . . . . . . . . . . . . . . 93.4 Ubergabe der Repositorybezeichnung an cvs . . . . . . . . . 103.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 Andern von Dateien in einem Arbeitsbereich 167.1 checkout und commit . . . . . . . . . . . . . . . . . . . . . . 167.2 update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177.3 Statusabfragen . . . . . . . . . . . . . . . . . . . . . . . . . . 197.4 remove . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

8 Uberwachung paralleler Anderungen 20

9 Benutzungsregeln 22

Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Glossar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

c©2003 Udo Kelter Stand: 09.03.2003

Dieser Text darf fur nichtkommerzielle Nutzungen als Ganzes und unverandert in elektronischer odergedruckter Form beliebig weitergegeben werden und in WWW-Seiten, CDs und Datenbanken aufgenom-men werden. Jede andere Nutzung, insb. die Veranderung und Uberfuhrung in andere Formate, bedarfder expliziten Genehmigung. Die jeweils aktuellste Version ist uber http://kltr.de erreichbar.

Einfuhrung in CVS 3

1 Einleitung

Das Concurrent Versions System (CVS) ist eines der bekannte-sten und verbreitetsten Konfigurationsmanagementsysteme (KMS).Seinen Erfolg verdankt es mehreren Vorteilen gegenuber anderen KMS:

– Es ist als public-domain-Software frei verfugbar.

– Es ist fur alle gangigen Plattformen erhaltlich. Fur die Bedien-schnittstellen sind plattformspezifische Varianten verfugbar, die andas jeweilige look and feel der Plattform angepaßt sind.

– CVS unterstutzt den lokalen und entfernten Zugriff auf ein Archiv.Beim entfernten Zugriff werden diverse Protokolle und Verfahrenzum Einloggen auf den Server und Transfer der Daten unterstutzt.

– CVS wurde und wird in sehr vielen Projekten eingesetzt und hatsich in der Praxis in doppelter Hinsicht bewahrt: Es lauft außerststabil, und sein Funktionsumfang und die Auslegung der Basisfunk-tionalitaten sind alltagstauglich.

Der Funktionsumfang von CVS deckt naturlich alle Grundfunktio-nalitaten eines KMS ab. Hinzu kommen diverse Administrationsfunk-tionen.

Ein wichtiges Merkmal von CVS besteht darin, daß die Sperrungvon Dokumenten beim Checkout aus einem Archiv nicht direkt un-terstutzt wird. In CVS ist die Strategie, ein Dokument beim Checkoutaus einem Archiv nicht zu sperren, eindeutig bevorzugt. Die Vor- undNachteile beider Strategien – zu sperren bzw. Varianten zuzulassenund 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 fur CVS bilden Sperren oberhalb derKernfunktionalitat nach, wobei nicht immer klar ist, wie sicher solcheImplementierungen sind.

Intern benutzt CVS intensiv RCS (Revision Control System). MitRCS konnen Versionen einer Datei lokal verwaltet werden. Von RCSstammen manche Meldungen, die bei der Benutzung von CVS ausge-geben werden.


Einfuhrung in CVS 4

2 Grobarchitektur

2.1 Verteilungsarchitektur

Bzgl. der Grobarchitektur muß unterschieden werden, ob das Versi-onsarchiv (das Repository in der Begriffswelt von CVS) lokal, alsoauf dem gleichen Dateisystem, auf dem auch der Entwickler arbeitet,oder entfernt existiert1.

Bei einem lokalen Versionsarchiv konnen die von einem Entwickleraufgerufenen CVS-Befehle direkt auf dem Archiv arbeiten.

Bei einem entfernten Versionsarchiv muß auf der Seite des Rech-ners, der das Versionsarchiv enthalt, ein Serverprozeß laufen, der uberNetzwerkverbindungen ansprechbar ist und die ihm ubermittelte CVS-Operation ausfuhrt. Auf dem Rechner, an dem der Entwickler arbei-tet, muß ein Programm (das “CVS-Front-end”) verfugbar sein, dasmit dem Benutzer kommuniziert, die Verbindung zum Serverprozeßherstellt und die Kommunikation mit dem Serverprozeß abwickelt, s.Bild 1.

CVS-Front-end

Entwickler

CVS-Server-Prozeß

Reposi-tory

Arbeits-

ServerArbeitsplatzrechner

bereich

Abbildung 1: Front-end und CVS-Server

1Bei verteilten Dateisystemen wie NFS konnen Dateisysteme, die in Wirklichkeitauf einem Server gespeichert sind, bei anderen Rechnern – typischerweise Arbeits-platzrechnern – eingespiegelt werden. Auf den Arbeitsplatzrechnern bemerkt manabgesehen von der Performance und einigen speziellen Details keinen Unterschiedzwischen lokal gehaltenen und eingespiegelten Dateisystemen. Ein Versionsarchiv,das in einem eingespiegelten Dateisystem liegt, ist im Sinne von CVS daher ein lokalvorhandenes Archiv, obwohl es nicht wirklich auf einer lokalen Platte gespeichertist.


Einfuhrung in CVS 5

Bei einem entfernten Zugriff entstehen durch die Rechnerkom-munikation diverse Probleme bzgl. der Sicherheit und der Auswahlder Kommunikationsprotokolle; auf diese Fragen gehen wir hier nichtnaher ein. Es durfte nicht uberraschen, daß das Einrichten eines ent-fernt zuganglichen CVS-Repositorys kompliziert ist und Grundwissenuber Rechnernetzwerke erfordert.

Ein besonders positiver Aspekt von CVS ist, daß im normalen Be-trieb, sobald das Repository eingerichtet ist, praktisch kein Unter-schied zwischen einem lokalen und einem entfernten Archiv zu bemer-ken ist.

2.2 Programm- und Bedienschnittstellen

CVS ist ein Datenverwaltungssystem in dem Sinne, daß es einen Da-tenbestand – ein CVS-Repository – einkapselt2 und nach außen hinbestimmte Operationen exportiert, die auf diesem Datenbestand ope-rieren. Diese Operationen sind sowohl von Entwicklungswerkzeugen(insb. Editoren) aus aufrufbar wie auch durch selbstandige Program-me, die Entwicklern eine Bedienschnittstelle anbieten.

Das originare CVS-System enthalt “nur” eine Kommandozeilen-Schnittstelle. Fur Anfanger, deren Erfahrung mit Rechnern durchSpiele oder Buropakete gepragt ist, sind solche Bedienschnittstellenungewohnt. Fur professionellere Anwender sind Kommandozeilen-Schnittstellen dagegen wichtiger als graphische Schnittstellen, da sieoft effizienter bedient werden konnen und insb. weil man durch sieCVS-Operationen innerhalb von Shell-Skripten aufrufen kann; Shell-Skripten dienen meist zur Automatisierung umfangreicherer Arbeits-vorgange.

Zusatzlich zur Kommandozeilen-Schnittstelle stehen diverse gra-phische Bedienschnittstellen fur CVS zur Verfugung. Diese basierenteilweise direkt auf der Kommandozeilen-Schnittstelle, d.h. wenn z.B.uber ein Menu eine CVS-Operation aufgerufen wird und ggf. uber einFormular Parameter erfaßt werden, dann wird aus diesen Angaben

2Daß diese Kapselung nicht sicher ist und leicht durchbrochen werden kann, solluns hier nicht storen.


Einfuhrung in CVS 6

letztlich eine Kommandozeile konstruiert und die Kommandozeilen-Schnittstelle wird mit dieser Kommandozeile aufgerufen. Manche gra-phischen Bedienschnittstellen zeigen diese Kommandozeile in einemProtokollfeld auch direkt an. Die Historie mehrerer Operationsaufrufeinnerhalb einer Sitzung kann so gut uberblickt werden, sofern man dieKommandos versteht.

Die eigentlich interessante Leistung graphischer Front-ends bestehteher in graphischen Darstellungen von Versionsabhangigkeiten oderDifferenzen zwischen Dateien und ggf. Editierfunktionen zum Zusam-menmischen von Varianten. Diese Funktionen sind bei den einzelnengraphischen Front-ends recht verschieden ausgepragt und stehen nichtim Zentrum des Themas dieses Lehrmoduls; wir werden daher hier nurdie 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 ersteStellungsparameter dieses Programms gibt die auszufuhrende CVS-Operation an, z.B. checkout , die weiteren Parameter beziehen sichdann auf die gewahlte Operation. Insgesamt hat der Aufruf folgendeForm:

cvs [cvs-optionen3] cvs-operation [cvs-op-optionen] {Parameter ... }

3Als Option bezeichnet man i.d.R. Parameter, die einen Namen haben. Stel-

lungsparameter werden dagegen durch ihre Position in der Parameterliste identi-fiziert. Man benutzt Optionen bei Parametern, fur die normalerweise Vorgabewerteausreichen und die nur selten explizit gesetzt werden. In solchen Fallen waren Stel-lungsparameter unpraktisch, weil die Parameterlisten extrem lang wurden und beiAufrufen fast alle Positionen Leerwerte enthielten. Hierzu ein Beispiel: Das UNIX-Kommando ls listet die Namen der Dateien im aktuellen Verzeichnis auf. Mit derOption -l , also mit dem Aufruf ls -l , wird eine ausfuhrliche Beschreibung jederDatei geliefert. Der Wertebereich dieses Parameters ist Boolean, Vorgabewert istfalse . Durch die Angabe von -l wird der Wert auf true gesetzt.

Bei den meisten Optionen ist der Wertebereich Boolean, es sind aber im Prinzipbeliebige Wertebereiche moglich, z.B. Texte oder Zahlen. In solchen Fallen wird dergewunschte Wert hinter dem Optionsbezeichner als eigenes Wort in der Komman-dozeile angegeben. Beim Kommando ls kann z.B. die Breite der Ausgabe mit der


Einfuhrung in CVS 7

Beispiele fur CVS-Operationen sind login , checkout , edit , com-

mit , add und update ; diese werden wir i.f. an Beispielen erlau-tern. Der volle Funktionsumfang von CVS ist sehr komplex; wirkonnen hier nur einen Bruchteil davon vorstellen. Vollstandige Be-schreibungen finden sich in der on-line-Dokumentation in Linux-Sy-stemen (Kommando: info cvs ) sowie in [Ce01]. Ferner werden aufhttp://www.cvshome.org/docs weitere Materialien angeboten.

3 Das Repository

3.1 Konzeptioneller Inhalt eines Repositorys

Konzeptionell enthalt ein CVS-Repository einen Dateibaum, dieBlatter darin – i.f. als “Dateien” bezeichnet – sind Dokumente, diei.a. in mehreren Versionen vorhanden sind. Verzeichnisse werden nichtexplizit versioniert.

Dateien haben Namen, wie in Dateisystemen ublich. Alle Versioneneiner Datei haben den gleichen Namen; Versionen einer Datei werdendurch eine Versionsnummer unterschieden. Die Versionsnummer istnicht Teil des Dateinamens.

In einem Arbeitsbereich eines Entwicklers liegen Kopien von einemoder mehreren Teilbaumen des Repositorys. Die CVS-Operationenarbeiten meist mit ganzen Teilbaumen, d.h. man braucht nicht jedeenthaltene Datei einzeln zu behandeln.

Der Arbeitsbereich enthalt von jeder Datei i.d.R. nur eine Version,die den gleichen Dateinamen wie im Repository hat. Es muß nichtunbedingt die neuste Version sein. Man erkennt also am Dateinamennicht, um welche Version es sich handelt. CVS merkt sich in bestimm-ten Hilfsdaten4, 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 ausfuhrlichere Darstellung findet sich in [KSP].4Jeder Arbeitsbereich enthalt ein Verzeichnis namens CVS , in dem diese Hilfs-

daten gespeichert werden. Dieses Verzeichnis darf nur durch cvs selbst verandertwerden.


Einfuhrung in CVS 8

Numerierung von Versionen. CVS benutzt folgendes Schema zurNumerierung von Versionen:

Beim Anlegen einer Datei erhalt diese als erstes die Nummer 1.1.Wenn eine neue Revision einer Datei angelegt wird, wird die hintersteZiffer um 1 hochgezahlt. Nach 1.1 kommen also die Versionsnummern1.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 ersteVariante von Version 1.9 hat also die Nummer 1.9.2.1. Varianten exi-stieren bekanntlich parallel; wenn von unserer Variante neue Versionenangelegt werden, gilt das oben Gesagte, d.h. es werden die Nummern1.9.2.2, 1.9.2.3 usw. vergeben.

Man kann mehrere Varianten zu einer Version anlegen. Die zwei-te Variante bekommt als Nummer x.y.4.1, in unserem Beispiel also1.9.4.1, die dritte Variante 1.9.6.1 usw. Die ungeraden Ziffern werdennicht benutzt, sondern fur interne Zwecke verwendet.

Jede Variante kann unabhangig Revisionen bilden, es entstehenso parallele Entwicklungszweige. Bild 2 zeigt ein Beispiel. Die ho-rizontalen Pfeile zeigen auf Nachfolge-Revisionen, die vertikalen aufVarianten.

1.9.4.1

1.9.2.2

1.8 1.111.101.9

1.9.2.1 1.9.2.3 ....

....

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ß aberdie Ursprungsversion, die zuerst existierte, eine um 2 Stellen kurzereNummer hat. Daran kann man nichts andern.

Man kann nach dem gleichen Schema auch noch Untervarianten bil-


Einfuhrung in CVS 9

den, z.B. indem man von Version 1.9.2.2 die erste Variante 1.9.2.2.2.1bildet.

3.2 Realisierung eines Repositorys

Ein Repository wird bei CVS durch ein Verzeichnis realisiert, das di-verse Dateien und Unterverzeichnisse enthalt. Diese interne Strukturinteressiert uns jetzt nicht.

In diesem Verzeichnis legt cvs alle Versionen der Dokumente, diesich unter Versionskontrolle befinden, und alle sonstigen, fur interneZwecke benotigten Daten ab. Der Inhalt dieses Verzeichnisses sollteallein durch cvs verandert werden.

Typischerweise unterscheiden sich aufeinanderfolgende Revisioneneines Dokument nur an wenigen Stellen voneinander. So konnte z.B.in einem Text von 100 Zeilen nur eine Zeile geandert oder eingefugtworden sein. CVS (genauer gesagt das intern verwendete RCS) nutztdiesen Sachverhalt intern zu einer Optimierung dahingehend aus, daßnur die Differenzen der Dateien gespeichert werden und nicht jedesmalder komplette Text.

3.3 Bezeichnung eines Repositorys

Auf einem Rechner und sogar in den Verzeichnissen eines einzelnenBenutzers konnen beliebig viele CVS-Repositories angelegt werden.Daher benotigt cvs eine Angabe, mit welchem Repository gearbeitetwerden soll.

Ein lokales Repository wird angegeben durch den absoluten Pfad-namen des Repositoryverzeichnisses.

Bei einem entfernten Repository muß der Name des Rechners an-gegeben werden, auf dem das Repository gespeichert ist, sowie derabsolute Pfadname des Repositoryverzeichnisses auf diesem entfern-ten Rechner. Diese beiden Namen werden mit weiteren Angaben, diewir anschließend bei der login -Operation erlautern werden, zu einereinzigen Zeichenkette zusammengefaßt.


Einfuhrung in CVS 10

3.4 Ubergabe der Repositorybezeichnung an cvs

Da man meist nur mit einem bestimmten Repository arbeitet, ware eslastig, dieses bei jedem Aufruf angeben zu mussen. Stattdessen kanndas Repository in der Umgebungsvariablen5 CVSROOT ubergeben wer-den. In der auf UNIX-Systemen verbreiteten c-Shell (csh) oder dertc-Shell (tcsh) ware folgendes Kommando einzugeben, um cvs an-zuzeigen, 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 einzugeben6:

export CVSROOT=/home/schmitz/pg/archiv

Das Repository kann aber auch beim Aufruf von cvs mittels derOption -d angegeben werden:

cvs -d /home/schmitz/pg/archiv .....

3.5 cvs login

Bei einem entfernt zugreifbaren Repository konnten Unberechtigte ver-suchen, auf das Repository zuzugreifen. Daher wird der Zugang nureinzelnen Benutzern erlaubt, die sich durch ein Paßwort ausweisenmussen. Hierzu dient die CVS-Operation cvs login; das Paßwortmuß interaktiv eingegeben werden, es wird intern aufbewahrt und an-schließend bei jedem Zugriff benutzt (auch uber mehrere Rechnersit-zungen hinweg). Mit cvs logout kann das Paßwort wieder geloschtwerden.

5Umgebungsvariablen sind eine weitere Technik, mit der in UNIX-Betriebssyste-men Parameter von einem Prozeß an einen Kind-Prozeß ubergeben werden konnen.Eine Umgebungsvariable hat einen Namen und einen Wert. Ein Prozeß kann Umge-bungsvariablen erzeugen und ihren Wert setzen. Ein von diesem Prozeß gestartetesProgramm erbt die Umgebungsvariablen und kann deren Werte dann lesen.

6Anstatt dieses Kommando bei jeder Sitzung erneut einzugeben ist es bequemer,es in die Datei $HOME/.bashrc bzw. $HOME/.cshrc einzutragen; die Umgebungsva-riable ist dann automatisch in jeder Sitzung gesetzt.

Den gleichen Effekt erzielt man bei den meisten graphischen Front-ends, indemman die Repositorybezeichnung in den Voreinstellungen eintragt.



Der Benutzername, unter dem man sich einloggen mochte, wird ineiner erweiterten Form des Repository-Namens angegeben (man kanngeteilter Meinung sein, ob das besonders elegant ist). Dies gilt auchfur das Kommunikationsprotokoll, das zur Kommunikation zwischenCVS-Front-end und CVS-Server verwendet werden soll. Z.B. bedeutetder Wert

:pserver:[email protected]:/home/schmitz/pg/archiv

in CVSROOT, daß mittels des pserver -Protokolls7 Verbindung mit demRechner xyz.abc.de aufgenommen werden soll, und zwar fur den dortbekannten Benutzer karl .

4 Anlegen eines Repositorys

Ziel der folgende Abschnitte ist, die wichtigsten CVS-Operationenan Beispielen zu erklaren. Die einzelnen dabei benutzten CVS-Operationen werden nicht im Detail erklart - hierzu sei auf [Ce01] unddie on-line-Dokumentation verwiesen. Das Ziel ist vielmehr, einen er-sten Uberblick zu geben und das Zusammenspiel der CVS-Operationenklarzumachen.

Es ist sinnvoll, die gezeigten Beispiele an einem Rechner praktischnachzuvollziehen8. Hierzu benotigt man ein installiertes Repository.Erst nachdem ein Repository vorhanden ist, konnen Arbeitsbereicheeingerichtet werden (mit Hilfe der Operation checkout ).

Das Einrichten eines verteilt zugreifbaren Repositorys ist kompli-ziert und kein Lernziel dieses Lehrmoduls. Sofern kein zentrales vor-konfektioniertes Repository verfugbar ist oder man auf einem nichtvernetzten Rechner uben will, muß mit einem lokalen Repository ge-arbeitet werden. Nachfolgend zeigen wir an einem Beispiel, wie einRepository lokal initialisiert werden kann. Die Kommandos unterstel-len die bash als Kommandointerpreter.

7Es gibt weitere Protokolle, die wir hier aber nicht betrachten.8Uber die WWW-Seite zu diesem Lehrmodul ist ein Shell-Skript erhaltlich, das

eine Sequenz von Kommandos mit Erlauterungen durchfuhrt.



1. Erzeugen eines leeren Repositorys. Im Beispiel legen wir dasRepository im home-Verzeichnis unter dem Namen archiv an:

export CVSROOT=$HOME/archiv

cvs init

Die CVS-Operation init erzeugt im angegebenen Verzeichnis ein lee-res Repository.

2. Anlegen einer initialen Verzeichnisstruktur im Repository.Angenommen, wir wollen die Programmquelltexte in einem Verzeich-nis src speichern, die Dokumentation in einem Verzeichnis docs ,darin zwei Unterverzeichnisse docs/handbuch und docs/install furdas Benutzerhandbuch und die Installationsanweisungen. Wir legenzunachst an einer beliebigen Stelle im Dateisystem ein Hilfsverzeich-nis initdirs an und erzeugen dort die gewunschten Verzeichnisse:

mkdir initdirs

mkdir initdirs/docs

mkdir initdirs/docs/handbuch

mkdir initdirs/docs/install

mkdir initdirs/src

Diese Struktur konnen wir nun mit Hilfe der CVS-Operation import

in das Repository ubernehmen. Dies ubertragt die Inhalte des Ver-zeichnisses, in dem sie aufgerufen wird, in das Repository. Wir mussenalso zunachst in unser Hilfsverzeichnis initdirs hineinnavigieren:

cd initdirs

cvs import -m "initiale Verzeichnisstruktur erzeugt" \

ws2003/propra x y

Der Schragstrich am Ende einer Zeile bedeutet, daß das begonneneKommando in der Folgezeile fortgesetzt wird.

Die Option -m ... (m wie message) erlaubt es, einen Kommentarzu hinterlegen.

Der erste Stellungsparameter ws2003/propra gibt ein Unterver-zeichnis innerhalb des Repositorys an, in dem die Verzeichnisstruktur



erzeugt werden soll; sofern noch nicht vorhanden, werden diese Ver-zeichnisse im Repository erzeugt. Auf diese Weise ist es moglich, furmehrere Arbeitsbereiche, die fur unterschiedliche parallele Aktivitatennotig sein mogen, mit einem einzigen Repository auszukommen.

Die beiden folgenden Stellungsparameter (x und y ) durfen nichtfehlen, sind aber im Moment uninteressant.

Man beachte, daß beim bisherigen Stand der Dinge unser Hilfsver-zeichnis initdirs nicht automatisch zu einem Arbeitsbereich gewor-den ist. Es wird nicht weiter benotigt und kann geloscht werden.

5 Anlegen von Arbeitsbereichen

Zu einem Repository konnen bekanntlich mehrere Arbeitsbereicheangelegt werden. In unserem Beispiel wollen wir im Verzeichnis$HOME/arbeit zwei Arbeitsbereiche ab1 und ab2 anlegen. Normaler-weise gehoren Arbeitsbereiche zu verschiedenen Entwicklern. Um dasBeispiel einfacher nachvollziehbar zu machen, fuhren wir hier alle Ope-rationen unter einem einzigen Benutzer aus. Die CVS-Operationenkonnten aber ebensogut in jedem Arbeitsbereich von einem anderenEntwickler durchgefuhrt werden. Wir legen zunachst entsprechendeleere Verzeichnisse an:

mkdir $HOME/arbeit

mkdir $HOME/arbeit/ab1

mkdir $HOME/arbeit/ab2

Anlegen konnen wir einen Arbeitsbereich mit der CVS-Operationcheckout (abgekurzt co ). Als impliziten Parameter hat auch die-se das Verzeichnis, in dem sie aufgerufen wird: in diesem Verzeichniswerden die CVS-Dateien fur einen Arbeitsbereich angelegt oder, so-fern schon vorhanden, korrigiert. Wir mussen also in unseren erstenArbeitsbereich wechseln:

cd $HOME/arbeit/ab1

cvs checkout -d . ws2003/propra



Der Parameter ws2003/propra bezeichnet den Teilbaum des Reposi-torys, der hierhin kopiert werden soll. Ohne die Option -d . wurdendie 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 vonws2003/propra aus erzeugt werden. Statt des vorstehenden Verzeich-nisses entsteht somit:

$HOME/arbeit/ab1/docs/handbuch

6 Anlegen von Verzeichnissen und Dateien im

Repository

Anlegen vn Textdateien Angenommen, wir wollen nun im Ver-zeichnis docs/handbuch die Datei hb.txt erstellen und unter Versi-onskontrolle nehmen. Hierzu benutzt man die CVS-Operationen add

und commit . add merkt eine Datei nur zur Eintragung in das Re-pository vor, eingetragen wird die Datei erst nach dem commit . Bei-de Kommandos mussen im jeweils betroffenen Verzeichnis ausgefuhrtwerden; wir navigieren also in unserem Beispiel zunachst 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 Da-tei verzichten. Ist keine Datei angegeben, durchsucht CVS das aktu-elle Arbeitsverzeichnis und dessen Unterverzeichnisse nach Dateien,die zur Eintragung in das Repository vorgemerkt sind, und fuhrt alleEintragungen durch.

Binardateien. Unter Binardateien verstehen wir Dateien, in denennicht darstellbare Byteinhalte vorkommen. Beispiele sind die gangigenFormate fur Bilder, Spreadsheets und mit gzip komprimierte Dateien.



Wir hatten bisher unterstellt, daß Dateiinhalte bei einem commit

vollig unverandert in das Repository ubertragen werden. Dies ist nichtvollig korrekt, in Wirklichkeit werden bestimmte kleinere Veranderun-gen vorgenommen. Eine der Veranderungen besteht darin, die Zei-lenendemarkierungen in den Dateien zu vereinheitlichen. Hierzu istanzumerken, daß die Zeilenendemarkierungen in den unterschiedlichenBetriebssystemen nicht einheitlich gehandhabt werden. Wurde ein Re-pository von mehreren Rechnern mit verschiedenen Betriebssystemenaus benutzt, ohne die Zeilenendemarkierungen zu vereinheitlichen, sowurden die Algorithmen zur Bildung der Differenzen zwischen Revisio-nen in jeder Zeile eine Anderungen feststellen und nicht mehr sinnvollarbeiten.

In Binardateien konnen zufallig auch Folgen von Byteinhaltenauftreten, die identisch mit einer Zeilenendemarkierung sind, abernaturlich keine solche darstellen. Diese Byteinhalte durfen offensicht-lich nicht gegen eine andere Darstellung eines Zeilenendes ausgetauschtwerden, hierdurch wurde der Dateiinhalt unbrauchbar werden. Durchdie Option -kb in der CVS-Operation add kann erzwungen werden,daß eine Datei vollig unverandert ubernommen wird. Wenn wir bei-spielsweise von irgendwoher die Bilddatei logo.gif in unseren Ar-beitsbereich kopiert hatten, wurden wir dieses Bild wie folgt in dasRepository ubernehmen:

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 imRepository (und nicht erst nach dem nachsten commit ).



7 Anlegen und Andern von Dateien in einem

Arbeitsbereich

7.1 checkout und commit

Das Neuanlegen von Dateien oder Verzeichnissen im Repository isteher die Ausnahme. Meist werden Dateien, die schon im Repositoryvorhanden sind, modifiziert. Hierzu werden sie mit der CVS-Operationcheckout in den Arbeitsbereich kopiert. Nach Beendigung der Ande-rung wird die neue Version mit commit wieder in das Repository uber-nommen.

In unserem Beispiel wechseln wir in den zweiten Arbeitsbereich underzeugen dort eine Kopie des kompletten Teilbaums, den wir eben imersten Arbeitsbereich angelegt haben.

cd $HOME/arbeit/ab2

cvs checkout -d . ws2003/propra

Wir finden anschließend in $HOME/arbeit/ab2/docs/handbuch unse-re Datei hb.txt . Wir navigieren jetzt in dieses Verzeichnis, hangeneine Zeile an die Datei an und fuhren 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 wor-den ist.

Um des Beispiels willen erzeugen wir jetzt noch eine weitere Dateiund 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 fertigsind und der neue Stand im Repository eingetragen ist, konnen wir,



wenn wir wollen, hb.txt ohne weiteres loschen, denn wir konnen sieja bei Bedarf wieder mit einem checkout restaurieren. In der Pra-xis wird man dies i.a. nicht tun, das Beispiel soll vielmehr folgendesklarmachen: Die ubliche Denkweise, wonach man seine “Originale” inseinen Arbeitsverzeichnissen hat und ggf. an anderer Stelle eine Si-cherungskopie, wird bei der Benutzung eines Repositorys sozusagenumgekehrt: die “Originale” befinden sich im Repository, die Arbeits-bereiche enthalten nur Kopien, die modifiziert sein konnen. Daherwird eine Datei in einem Arbeitsbereich, die eine korrespondierendeDatei im Repository hat, oft als Kopie bezeichnet.

7.2 update

Wir haben nun in unseren beiden Arbeitsbereichen Kopien der glei-chen Dateien aus dem Repository vorliegen, wobei im Arbeitsbereichab1 eine Datei fehlt und eine einen veralteten Stand hat. Aus Sicht desArbeitsbereichs ab1 entspricht dies der Situation, daß jemand andersdie Dokumente inzwischen weiterentwickelt hat und daß die Anderun-gen lokal nachvollzogen werden mussen. Hierzu ist die CVS-Operationupdate verfugbar.

Bei einem Aufruf von update konnen Dateien oder Verzeichnisseangegeben werden, die auf den neuesten Stand gebracht werden sollen.Bei Verzeichnissen werden das Verzeichnis und alle direkten und in-direkten Unterverzeichnisse durchlaufen und alle gefundenen Dateienbehandelt. Sofern die im Arbeitsbereich befindliche Kopie identischmit der neusten Revision im Repository ist, passiert nichts. Andern-falls wird eine Korrektur erforderlich, wobei verschiedene Falle zu un-terscheiden sind. Bezuglich des Zustands der Datei im Arbeitsbereichsind folgende Falle von Interesse:

(A) die Datei existiert noch nicht oder nicht mehr im Arbeitsbereich

(B) Die Datei existiert im Arbeitsbereich und entsprach bei ihremcheckout oder dem letzten update oder commit der RevisionX. Seit diesem Zeitpunkt konnen sowohl im Arbeitsbereich alsauch im Repository Veranderungen eingetreten sein. FolgendeFalle sind denkbar:



(1) die Datei im Arbeitsbereich ist unverandert.

(2) die Datei im Arbeitsbereich wurde verandert.

(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 Falle wie in der folgenden Tabelle angegeben.Im Fall (B1a) passiert nichts; in den anderen Fallen gibt update einenKennbuchstaben und den Dateinamen aus.

Fall Reaktion Kenn-buchstabe

(A) Datei wird neu erzeugt U

(B1a) keine Anderung -

(B1b) Datei wird auf den gleichen Stand wie dasRepository gebracht

U

(B2a) keine Anderung M

(B2b) automatische Mischung der Anderungen;hierbei traten ...... keine Mischkonflikte auf M... Mischkonflikte auf C

Daruber hinaus existieren u.a. die folgenden Meldungen:

A Die Datei wurde im Arbeitsbereich angelegt, muß aber noch mitcommit gesichert werden.

R Die Datei wurde im Arbeitsbereich geloscht, die Loschung mußaber noch mit commit im Repository nachvollzogen werden.

In unserem Beispiel andern wir zunachst die Datei hb.txt abund provozieren so einen Mischkonflikt. Danach veranlassen wir einupdate fur das komplette Verzeichnis docs :

cd $HOME/ab1

echo ’nur Mut!’ >> docs/handbuch/hb.txt

cvs update docs



update legt die Datei nochn.txt neu an und mischt die Anderun-gen in hb.txt ; hierbei wird eine Warnung ausgegeben – auf solcheWarnungen ist zu achten! – und die ursprunglich im Arbeitsbereichvorhandene Datei unter einem anderen Namen verwahrt. hb.txt hatanschließend folgenden Inhalt:

aller Anfang ist schwer

<<<<<<< hb.txt

nur Mut!

=======

nun ja

>>>>>>> 1.2

Oberhalb der Zeile ======= steht der bisher im Arbeitsbereichvorhandene Text, darunter der Text gemaß der letzten Version im Re-pository.

Option -D . Normalerweise zieht update alle Anderungen nach, dieseit dem Anlegen der Dateien im Arbeitsbereich (bzw. seit dem letztenUpdate) im Repository eingetragen wurden. Dies geht manchmal zuweit. So kann an einem bestimmten Datum ein konsistenter Zustandvorhanden gewesen sein, seitdem kann aufgrund nicht abgeschlossenerArbeiten ein inkonsistenter Zwischenzustand im Repository eingetra-gen sein, den nicht jeder sehen mochte. In solchen Fallen kann durchdie Option -D datum bewirkt werden, daß nur die Anderungen bis zudiesem Datum nachvollzogen werden.

7.3 Statusabfragen

Daß unsere Datei hb.txt Revision 1.2 ist, kann man ihr am Dateina-men nicht ansehen. Die Versionsnummer und diverse andere Angabenzum Zustand von Dateien im Arbeitsbereich kann man mit der CVS-Operation status abfragen. Beispiel:

cvs status hb.txt



7.4 remove

Es kann naturlich auch der Fall eintreten, daß wir eine Datei kom-plett loschen wollen. Es reicht jetzt nicht mehr aus, die Datei ein-fach im Arbeitsbereich zu loschen, das nachste cvs update wurde siewiederherstellen. Stattdessen muß sie explizit im Repository geloschtwerden. Hierzu dient die CVS-Operation remove : sie merkt vor, daßdie angegebenen Dateien oder Verzeichnisse beim nachsten commit imRepository geloscht werden sollen. Vor dem cvs remove mussen dieDateien im Arbeitsbereich geloscht worden sein. Hierzu ein Beispiel(wir unterstellen, daß die Datei versuch1.java vorher mit add undcommit im Repository eingetragen worden ist):

rm versuch1.java

cvs remove versuch1.java

cvs commit versuch1.java

8 Uberwachung paralleler Anderungen

Obwohl CVS Sperren nicht direkt unterstutzt, bietet es Mechanismenan, durch die bei entsprechender Disziplin der Entwickler verhindertwerden kann, daß mehrere Entwickler die gleiche Datei editieren.

Die Uberwachung paralleler Anderungen kann fur einzelne Da-teibaume des Repositorys ein- und ausgeschaltet werden. Hierzu dientdie CVS-Operation watch

cvs watch on [-l] [-R] dateien ....

Diese CVS-Operation schaltet die Uberwachung fur die angegebenenDateien und Verzeichnisse ein. Wenn ein Verzeichnis angegeben wird,wird dort uberwacht, ob neue Dateien angelegt werden; fur die neuenDateien wird die Uberwachung automatisch eingeschaltet. Normaler-weise arbeitet watch rekursiv, wenn also ein Verzeichnis angegebenwird, auch auf allen direkt oder indirekt enthaltenen Verzeichnissenund Dateien. Das rekursive Arbeiten kann durch die Option -l (l wielokal) abgeschaltet werden. CVS kann aber auch so konfiguriert wer-



den, daß das lokale Arbeiten voreingestellt ist; in diesem Fall bewirktdie Option -R , daß rekursiv gearbeitet wird.

Abgeschaltet werden kann die Uberwachung durch

cvs watch off [-l] [-R] dateien ....

Die Optionen und Parameter werden hier genauso behandelt wie beiwatch on .

Die Uberwachung andert die Wirkung des checkout : wahrenddieses bisher Dateien im Arbeitsbereich mit Lese- und Schreibrechtenanlegte, werden nun nur noch Leserechte eingeraumt.

Wenn ein Entwickler nun eine Datei verandern mochte, muß ervorher eine weitere CVS-Operation aufrufen: edit 9. Beispiel:

cvs edit hb.txt ...

Diese Operation hat folgende Effekte:

– Alle Entwickler, die die angegebene Datei uberwachen, werden vonder geplanten Anderung informiert. Das CVS-System ist so konfi-gurierbar, daß den betroffenen Benutzern eine elektronische Nach-richt geschickt wird (dies ist allerdings nicht voreingestellt).

– Der Benutzer, der cvs edit aufgerufen hat, wird ab sofort vonAnderungen anderer Entwickler an der Datei informiert.

– Es werden Schreibrechte an den Dateien eingeraumt.

Die Datei kann nunmehr verandert werden, und der neue Standkann wie ublich mit commit in das Repository ubertragen werden.Das commit zeigt das Ende der Bearbeitung an, daher werden als Sei-teneffekt die Schreibrechte wieder entfernt, ferner wird der Entwicklervon Anderungen anderer Entwickler an der Datei nicht mehr benach-richtigt,

Sofern aus irgendeinem Grund die Bearbeitung der Datei ohnecommit abgebrochen werden muß, ist die CVS-Operation unedit zubenutzen. Diese hat folgende Effekte:

9Man kann naturlich auch die Rechte direkt im Dateisystem andern und dieCVS-Mechanismen so unterlaufen, d.h. die CVS-Mechanismen sind in dieser Hin-sicht nicht sicher.



– Die angegebenen Dateien werden auf den Zustand zuruckgesetzt,den sie beim letzten commit , update bzw. checkout hatten.

– Die Benachrichtigung uber Anderungen anderer Entwickler an derDatei wird aufgehoben.

– Die Schreibrechte an den Dateien werden wieder entzogen.

9 Benutzungsregeln

In den bisherigen Abschnitten wurden die wichtigsten Funktionen vonCVS eingefuhrt, wobei offen blieb, wie sie sinnvoll und systematischeingesetzt werden sollten. Als Abschluß folgen daher einige Benut-zungsregeln:

1. Man sollte so oft wie moglich die Dateien in einem privaten Ar-beitsbereich mit update auf den neuesten Stand bringen. Dies giltbesonders fur Dokumente, die bisher noch unverandert sind undjetzt bearbeitet werden sollen; sie konnten seit dem checkout vonjemand anderem verandert worden sein.

2. Es sollten nur compilierfahige Programme bzw. allgemeiner gesagthinreichend konsistente Dokumente in das Repository eingetragenwerden. Der notwendige Grad an Konsistenz hangt vom Dokument-typ und ggf. vom Arbeitsstil einer Gruppe ab. Jedenfalls muß nacheiner Eintragung immer damit gerechnet werden, daß ein anderesGruppenmitglied diese Revision als Basis eigener Arbeiten benutzt.

3. Neue Zustande von Dokumenten sollten moglichst fruh in das Re-pository eingetragen werden.

Dies sieht auf den ersten Blick wie ein Widerspruch zur vorheri-gen Regel aus, ist es aber nicht. Beide Regeln zusammen bedeuten,daß man umfangreichere Anderungen moglichst in eine Folge klei-nerer Anderungen aufteilt, die jeweils zu einem konsistenten Zwi-schenzustand fuhren. Dahinter steckt die ganz generelle Lebens-weisheit, nicht parallel an vielen Problemen herumzubasteln, son-dern sich auf wenige Dinge zu konzentrieren und diese zugig zumAbschluß zu bringen.



4. Arbeitsgruppen, die noch wenig Erfahrung in Teamarbeit haben– hierzu zahlen insbesondere Gruppen in Programmierpraktikaund studentische Projektgruppen – sollten systematisch edit undunedit einsetzten, um unkontrollierte Parallelarbeit am gleichenDokument zu verhindern. Der Mehraufwand zum Aufruf dieserCVS-Operationen ist vergleichsweise gering, wahrend die Behebunginkompatibler Anderungen viel Zeit kosten und Arger verursachenkann.

5. CVS macht Planung und Kommunikation in der Gruppe nicht uber-flussig. Wenn es haufig dazu kommt, daß verschiedene Entwicklerdas gleiche Dokument bearbeiten und vielleicht sogar Mischkon-flikte auftreten, kann eine schlechte Modularisierung des Systemsund eine ungeschickte Arbeitsaufteilung die Ursache sein; ein KMSmacht 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/ erhaltlich)

[Ti85] Tichy, Walter F.: RCS - a system for version control; Software- Practice & Experience 15:7, p.637-654; 1985/07

[KM] Kelter, U.: Lehrmodul “Einfuhrung in das Konfigurationsmana-gement”; 2003

[KSP] Kelter, U.: Lehrmodul “Kommandosprachen und Shell-Pro-grammierung”; 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 Bestatigen von Anderungen

cvs edit: CVS-Operation, mit der man ankundigen kann, daß eine Dateieditiert werden soll



cvs remove: CVS-Operation zum Loschen von Dateien im Repository

cvs status: CVS-Operation zur Anzeige des Zustands von Dateien in einemArbeitsbereich

cvs update: CVS-Operation, mit der Dateien, die sich im Arbeitsbereichbefinden, auf den neuesten Stand gemaß Repository gebracht werdenkonnen; eine Variante von update erlaubt es, Varianten von Dateienzu mischen

cvs watch: CVS-Operation, mit der die Uberwachung von Dateien und Ver-zeichnissen ein- und ausgeschaltet werden kann

CVSROOT: Umgebungsvariable, die den Namen des von cvs zu benutzendenRepositorys enthalt

Repository (im Kontext von CVS): Synonym zu Versionsarchiv; technischgesehen der Name eines Verzeichnisses


Index

Arbeitsbereich, 13Arbeitsplanung, 23Archiv, siehe Repository

Benachrichtigung, 20Binardateien, 14

Concurrent Versions System, 3CVS, 3

Arbeitsbereich, 11Benutzungsregeln, 22Front-end, 3–5

graphisches, 5Kommandozeilen-Schnittstelle, 5

cvs, 6add, 14, 16, 23checkout, 13, 16, 21, 23co, 13commit, 14–16, 21, 23CVSROOT, 10edit, 21–23import, 12init, 11login, 10logout, 10remove, 20, 23Repositorybezeichnung, 10status, 19, 24unedit, 21update, 17, 19, 22, 24

Kennbuchstaben, 18watch, 20, 24

CVSROOT, 24

Differenzen, 6, 9

KMS, 3

Konfigurationsmanagement∼system, 3

Kooperation, 22Kopie, 17

Mischkonflikt, 18, 23Darstellung, 19

Option, 6

parallele Anderungen, 20

RCS, 3, 9Repository, 4, 24

Aktualisierung, 17Anlegen, 11Anlegen von Dateien, 14Anlegen von Verzeichnissen, 15Bezeichnung, 9entfernter Zugriff, 3, 4, 9konzeptioneller Inhalt, 7leeres, 11Realisierung, 9

Revision, 8, 17

Sperre, 3, 20Stellungsparameter, 6

Variante, 8Versionsnummer, 7

Zeilenendemarkierung, 14

25

Einf uhrung in CVS -...

Documents

Transcript of Einf uhrung in CVS -...