Willemers Informatik-Ecke
Versionsverwaltungen sind unentbehrliche Tools in der professionellen
Softwareerstellung. Solche Systeme sorgen dafür, dass alte Entwicklungsstände
archiviert werden und dass immer nur eine Änderung parallel durchgeführt
wird, so dass es keine Reibungsverluste gibt, wenn mehrere Entwickler an
einer Software gemeinsam arbeiten.
SCCS (Source Code Control System)
SCCS gilt als erste Software zur Versionsverwaltung und wurde 1972 von
Marc J. Rochkind geschrieben.
Es gehört zum POSIX-Standard und wird üblicherweise bei
kommerziellen UNIX-Versionen mitgeliefert.1)
Seit Dezember 2006 ist SCCS OpenSource und wird zu einem verteilten
Versionsverwaltungssystem weiterentwickelt. Siehe http://sccs.berlios.de2)
Man teilt sich einen gemeinsamen Sourcenstand. Für
jede Datei wird eine SCCS-Datei angelegt. Ihr Name bildet sich aus dem der
zu verwaltenden Datei und hat den Präfix >>s.<<. Darin werden die
Differenzen der verschiedenen Stände gespeichert.3)
admin
Eine Datei wird mit dem Befehl admin unter SCCS gestellt.
Sie erhält dabei die Standardversionsnummer 1.1 und ist nach Ausführung des
Befehls erst einmal
verschwunden. Statt ihrer gibt es nun die SCCS-Datei, die s. vor dem
Namen trägt.
zum Lesen holen
Will man die Datei nur lesen, kann man mit dem Befehl get eine
schreibgeschützte Version aus der SCCS-Datei erhalten.
Änderungen durchführen
Sobald eine Änderung gemacht werden soll, wird mit dem
Kommando get -e die entsprechende Datei
ausgecheckt. Dabei wird der Aufrufer zum Besitzer dieser Datei und erhält
Schreibrecht. Da eine Datei mit Schreibrecht von niemandem ausgecheckt
werden kann, kann nur einer mit dieser Datei arbeiten.
Bei jedem Auschecken wird die Nummer hinter
dem Punkt inkrementiert. Die nächste Version wäre also 1.2.
Will man einen Release wechseln, also die Nummer vor dem Punkt
hochziehen, gibt man beim get -e auch den Parameter
-r gefolgt von der neuen Releasenummer an.
Einstellen der Änderung
Sind die Änderungen durchgeführt, wird die Datei mit dem Befehl
delta wieder eingecheckt.
Dabei werden alle Änderungen in die SCCS-Datei übernommen. Die
Originaldatei verschwindet wieder. Vorher erscheint ein Prompt und bittet
um einen Kommentar, in dem man festhalten kann, welche Änderung gemacht
wurde.
War alles nur Spaß!
Sollen die
gemachten Änderungen doch nicht in das System gelangen, kann man mit dem
Befehl unget den Stand wieder in die Situation zurückbringen, die
vor dem Auschecken bestand.
| Befehl | Wirkung |
|---|
| delta Datei | Datei einchecken |
| get Datei | Datei zum Lesen aus dem SCCS holen |
| get -e Datei | Datei zum Verändern auschecken |
| unget Datei | Auschecken revidieren |
RCS (Revision Control System)
RCS gehört zur GNU Software und ist damit frei erhältlich. Es ähnelt in
vieler Hinsicht SCCS. Auch hier werden die Änderungen in separaten Dateien
abgestellt. Allerdings werden die RCS-Dateien in einem eigenen Verzeichnis
namens RCS abgelegt.2)
Unter RCS stellen
Nachdem im Sourceverzeichnis das Verzeichnis RCS angelegt wurde, reicht
der Befehl ci (check in) um eine Datei unter RCS-Kontrolle zu
nehmen. Mit dem gleichen Befehl werden später geänderte Dateien wieder in
das System eingecheckt. Das System bittet um eine Kommentierung der
Änderung. Wie beim SCCS verschwindet dann die Originaldatei
und alle Informationen liegen in der RCS-Datei, die im Verzeichnis RCS
liegt und wie die Originaldatei heißt, allerdings >>,v<< angehängt
bekommt.
Zum Lesen und zur Änderung holen
Der Befehl co holt die letzte Version zum Lesen aus dem RCS
heraus. Erst co -l erzeugt eine Version, die änderbar ist.
Ein paralleles Bearbeiten der Datei ist dann nicht mehr möglich, bis die
Datei mit ci wieder unter RCS gestellt wird.
Die feinen Unterschiede
Neue Releases werden durch den Parameter -r beim Einchecken angelegt. Soll
der Unterschied zwischen zwei Versionen ermittelt werden, wird dazu
der Befehl rcsdiff verwendet. Ohne Parameter werden die
ausgecheckte Version mit der zuletzt eingecheckten Version verglichen. Es
können aber auch beliebige Versionen verglichen werden. Die Versionen
werden durch -r angegeben.
Man kann jeder Datei zuordnen, welcher Programmierer sie ändern darf.
Dazu wird der Verwaltungsbefehl rcs mit der Option -a gefolgt von
den Namen der Programmierer aufgerufen. Mit der Option -e kann einzelnen
Programmierern das Recht entzogen werden, die Datei zu ändern.
Zusammenspiel mit make
Durch Ergängzungen im Makefile kann man erreichen, dass das zum Compilieren
die aktuellen Versionen aus dem RCS herausgeholt werden. Die Suffixregel wird
so gesetzt, dass die Objektdatei nicht aus dem C Quellcode generiert wird,
sondern aus der Extension der RCS-Datei. Dafür muss in der ersten Aktionszeile
die Datei zum Lesen ausgecheckt werden.
.c,v.o:
co $<
cc -c $*.c
~ rm -f $*.c
|
Die Tilde (~) verhindert, dass make abbricht, wenn rm
misslingt.
CVS (Concurrent Versions System)
CVS (Concurrent Versions System) dient dazu, bei der Softwareentwicklung die Fortentwicklung der Projekte zu speichern. Es ermöglicht einerseits den Zugriff auf ältere Versionen und andererseits den unproblematischen Zugriff durch mehrere Programmierer.
CVS arbeitet projektorientiert
Während RCS (Revision Control System) und SCCS nur einzelne Dateien kontrollieren, arbeitet CVS projektorientiert. Es wird pro Projekt ein Repository angelegt, das mehrere Module (Verzeichnisse) und darunter wieder mehrere Dateien aufnehmen kann. Auch wenn es möglich ist, mehrere Projekte in einem einzigen Repository als Module abzulegen, wird dies hier nicht verfolgt. Die minimale Ersparnis steht in keinem Verhältnis zum entstehenden Durcheinander und dem Verlust an Flexibilität.
Umgebungsvariable CVSROOT
Jeder Entwickler hat ein eigenes Arbeitsverzeichnis
Das Repository ist der Ort, wo CVS die Sourcen und ihre Entwicklung zentral abspeichert. Hier hat kein Entwickler etwas zu suchen. Um die Sourcen weiter zu bearbeiten, legt sich jeder Entwickler an einer beliebigen anderen Stelle ein Arbeitsverzeichnis an und arbeitet dort.
Der Ort des Repository wird in der Environment-Variablen CVSROOT festgehalten.
Unter UNIX kann diese in der /etc/profile oder in den
jeweiligen lokalen rc-Dateien, beispielsweise .bashrc definiert werden.
Anlegen eines Repositories
cvs init
Das Verzeichnis, auf das CVSROOT zeigt, muss angelegt werden. Anschließend
wird mit dem Befehl cvs init das Repository angelegt. Damit sind
die internen Verwaltungsdateien erzeugt. Noch gibt es aber keinen Inhalt.
Ein Modul muss aber in jedem Fall eingetragen werden, da ansonsten keine
Arbeitsumgebung aus dem Repository generiert werden kann.
cvs import
Das Eintragen eines
Moduls wird durch den Befehl cvs import erreicht. Bei kleineren
Projekten ist es naheliegend, das leere Basisverzeichnis anzulegen. Besser
ist eine thematische Untergliederung in Module bzw. Verzeichnisse.
export CVSROOT=/home/cvs
mkdir $CVSROOT
cvs init
mkdir worksrc
cd worksrc
cvs import -m "Basisverzeichnis" . V1_0 R1_0
|
Jetzt existiert ein Repository, aus dem man sich an anderer Stelle ein
Arbeitsverzeichnis erstellen kann. Das eben angelegte Verzeichnis
worksrc wird nun nicht mehr benötigt und kann entfernt werden.
Man kann es natürlich auch als Arbeitsverzeichnis weiterverwenden.
Dateien aus dem Repository holen
cvs checkout
Um erstmalig mit den Sourcen arbeiten zu können, muss mittels des Befehls
cvs checkout mindestens ein Arbeitsverzeichnis aus dem Repository
erzeugt werden. Da oben bereits ein leeres Basisverzeichnis angelegt wurde,
kann man an beliebiger Stelle ein Arbeitsverzeichnis anlegen.
cvs checkout .
cvs checkout unix
|
In der ersten Zeile wird das Hauptverzeichnis eines Projektes mit allen Unterverzeichnissen in das Arbeitsverzeichnis übernommen. Die zweite Zeile holt nur das Modul unix und seine Unterverzeichnisse aus dem Projekt heraus.
Änderungen im Repository abstellen
cvs commit
Während bei anderen Versionssystemen die zu bearbeitenden Dateien reserviert
werden müssen, ist dies bei CVS nicht erforderlich. Die geänderten Dateien
werden mit dem Befehl cvs commit in das Repository abgestellt.
Sicherer als das Abstellen einzelner Dateien ist das Angeben der Modulnamen,
da CVS selbst merkt, was sich geändert hat.
Neue Dateien hinzufügen
cvs add
Neue Dateien werden mit cvs add gefolgt vom Dateiname im Repository
angemeldet. Beim nächsten Einstellen der Änderungen wird diese Datei auch
hinzugefügt.
Dateien aus dem Repository entfernen
cvs remove
Wenn eine Datei entfernt werden soll, muss sie zunächst im Arbeitsverzeichnis
gelöscht werden. Dann kann sie mit dem Befehl cvs remove Dateiname
aus dem Repository entfernt werden.
rm oldfile.cpp
cvs remove oldfile.cpp
cvs commit oldfile.cpp
|
Rückgriff auf alte Versionen
cvs diff
Will man sehen, was sich seit der letzten Version geändert hat, verwendet man
den Befehl cvs diff mit dem Dateiname als Parameter. Dieser
vergleicht die aktuell im
Arbeitsverzeichnis vorliegende Version mit derjenigen, die im Repository
liegt. Hat man die aktuelle Version schon abgestellt, kann man angeben, zu
welcher Version man die aktuelle vergleichen will. Dazu dient der Parameter
-r. Schließlich ist es auch möglich, zwei alte Versionen miteinander
zu vergleichen, indem man den Parameter -r zweimal angibt.
cvs diff myfile.cpp
cvs diff -r 1.1 myfile.cpp
cvs diff -r 1.1 -r 1.2 myfile.cpp
|
Welche Version einer Datei vorliegen, kann man sich mit cvs status
Dateiname anzeigen lassen.
Releases
cvs tag
Soll eine Release der Software erstellt werden, besteht diese aus den
verschiedensten internen Versionen des CVS. Um einen zusammengehörigen
fertigen Stand zu markiieren, gibt es den Befehl cvs tag, gefolgt
von einem Bezeichner.
Damit werden allen aktuell im Arbeitsverzeichnis abgestellten Dateien ein
Vermerk angeheftet, anhand dessen man später jederzeit wieder diese Version
herstellen kann. Dazu wird ein cvs checkout Befehl mit der Option
-r verwendet.
cvs tag alfa0_8
cvs checkout -r alfa0_8 .
|
UNIX als CVS Server
Anstatt die Verwaltung auf einem Netzlaufwerk durchführen zu lassen, kann
CVS auch als Client-Server Applikation installiert werden.
Auf dieser Basis arbeiten viele Open Source Projekte sogar weltweit über
das Internet zusammen.
Erster Schritt ist die Installation des CVS-Servers. Es wird ein zentrales
Repository angelegt. Das dafür benötigte Verzeichnis kann überall liegen.
Als Beispiel sei hier /home/cvs gewählt. In diesem Verzeichnis wird ein
Verzeichnis CVSROOT (in Großbuchstaben) angelegt.
Nun geht es daran, die Rechte korrekt zu setzen.
Um neue Repositories einzurichten, muss jeder Entwickler das Recht haben,
in /home/cvs ein Verzeichnis anzulegen. Dies erreicht man
beispielsweise, indem man die folgenden Rechte zuordnet.
chgrp prog /home/cvs
chmod 775 /home/cvs
|
Nun ist jedes Mitglied der Gruppe prog berechtigt, in diesem Verzeichnis
neue Verzeichnisse anzulegen. Wer in der Gruppe prog ist, läßt sich leicht
in der /etc/group steuern.
Der Zugriff erfolgt auf der Basis der remote Shell, also des rshd
Dementsprechend müssen für jeden
Anwender eine Datei .rhosts im Heimatverzeichnis angelegt werden.
UNIX als Client
Im nächsten Schritt müssen die Daten in den Server eingecheckt werden.
Dazu wechselt man in das Verzeichnis, in dem die Dateien stehen, die man
in das Repository stellen möchte. Dann wird die Umgebungsvariable CVSROOT
besetzt. Mit ihr wird Anwender, Rechner und Pfad festgelegt.
export CVSROOT=:ext:arnold@gaston:/home/cvs
cvs import -m "Informatik-Ecke" informatik Willemer BasisRel
|
Danach stehen die Dateien allen Rechnern zur Bearbeitung zur Verfügung.
Auschecken einer Arbeitsumgebung
Nachdem die Daten eingecheckt sind, sucht man sich ein Arbeitsverzeichnis,
in dem man an den Sourcen arbeiten möchte. Hier führt man einen Checkout
aus.
cd my/src
cvs checkout informatik
|
Danach ist unter my/src ein neues Verzeichnis informatik
angelegt worden.
Darin finden sich die Quelldateien. Hier kann man editieren und nach
erfolgreichem Abschluss die Datei per commit wieder ins CVS einstellen.
Arbeitszyklus
CVS erkennt, welche Dateien sich geändert haben, verlangt für jede Änderung
einen Kommentar und stellt die Änderungen zur Verfügung. Arbeitet man in
einem Team, ist es sinnvoll, regelmäßig mit cvs update den aktuellsten
Stand in das Arbeitsverzeichnis zu laden. Da dies die Kollegen auch tun
werden, ist es erforderlich, dass ein per commit eingestellter Stand
auch mindestens kompilierbar ist.
Windows-Client WinCVS
Auch für MS-Windows gibt es einen CVS-Client, der auf einen UNIX-Server
zugreift.
Unter Admin - Preferences wird die CVSROOT Umgebung in einem Dialog
festgelegt. Als Authentifizierung wird in diesem Fall rhosts gewählt.
Man kann auch ssh wählen, wenn die Sourcen so fantastisch kommentiert
sind, dass ein Angreifer mit einem Netzlauschangriff wirklich Vorteile
gewinnen könnte.
Pfad, Host und User werden analog zur UNIX Umgebung festgelegt.
Import
Sollen Windowsquellen in das Repository importiert werden, sucht man im linken
Baum das gewünschte Verzeichnis aus und klickt es einmal an. Durch den
Menüpukt Create - Import Module oder über den rechten Mausklick mit dem
entsprechenden Punkt kann man dieses Verzeichnis für den Import wählen.
Es startet ein Dialog, der den Namen des Moduls erfragt, den Vendor, die
Release und eine Message.
Auschecken
Um die Daten auf irgendeinem Rechner bearbeiten zu können, muss zuerst
ein Arbeitsverzeichnis ausgecheckt werden.
Unter dem Menüpunkt Create - Checkout module kann man dann angeben, welche
Module lokal exportiert werden sollen. Änderungen werden dann unter
Modify - Commit abgestellt.
Änderungen Einchecken
Nachdem Dateien verändert wurden, kann man das Modul anwählen und im Menü
Modify - Commit wählen. Es werden nur die Dateien eingecheckt, die geändert
worden sind.
Neue Dateien können mit Modify - Add selection oder Add binary dem Modul
hinzugeführt werden.
Quelle: http://www.cvshome.org
1 vgl. http://de.wikipedia.org/wiki/Source_Code_Control_System
2 Freundlicher Hinweis von Jörg Schilling v. 26.7.2011.
3 vgl.
Detering, Reinhard: UNIX Handbuch System V. Sybex, 1989. S. 637ff. und
Illik, J. Anton: Programmieren in C unter UNIX. Sybex,1990. S. 652ff.
2 vgl. Husain/Parker et al: Red Hat Linux
Unleashed. SAMS, 1996. pp. 890.