GNU-RCS: Quelltextverwaltung auf die komfortable Art
Egal, wie groß ein Software-Projekt ist, ob man daran alleine oder in einer Gruppe arbeitet: Immer dann, wenn ein Quelltext zukünftigen Änderungen unterworfen sein wird, erweist sich der Einsatz des GNU-RCS zur Verwaltung der Quellen als vorteilhaft.
Man könnte meinen, daß eine Thematik, bei der es um Software geht, die im Rahmen des GNU Projektes verfügbar ist, eher in die Rubrik „Unix und seine Tools“ gepaßt hätte. Aber dem ist (glücklicherweise) nicht so. GNU-RCS wurde nämlich, wie viele andere GNU-Tools auch, für TOS portiert. Zudem läuft es nicht nur unter Linux oder MiNT, sondern auch unter Standard-TOS oder MagiC. Somit ist es also für jedermann verfügbar.
Die Idee
Stellen Sie sich vor, Sie haben die Binaries zu Ihrem Tool xyz erfolgreich unter die Leute gebracht, und es gab auch schon einige verbesserte Versionen. Nun passiert das, was in der Praxis leider kaum vermeidbar ist: Es hat sich ein Fehler eingeschlichen, der in älteren Versionen der Software noch nicht vorhanden war. Sofern Sie die Quellen aller bisherigen Programmversionen aufbewahrt haben, läßt sich ein solcher Bug oft durch einen Vergleich der Quelltexte identifizieren. Ohne die alten Quellen ist guter Rat allerdings teuer, und die Fehlersuche wird erschwert. Selbst dann, wenn die Ursache des Fehlers anhand der aktuellen Quelltexte zu identifizieren ist, sind diese gemäß Murphys Gesetz gerade in einem Zustand, der es nicht erlaubt, eine neue funktionsfähige Programmversion zu erzeugen. Der Fehler müßte daher zunächst nur in den alten Quelltexten behoben werden. Die Quintessenz: Alte Quelltexte sollte man aufheben, um für den Fall des Falles gewappnet zu sein.
Man mag einwenden, daß das Aufbewahren verschiedener Versionen eines Quelltextes nicht nur Platz auf der Festplatte frißt, sondern auch eines gewissen organisatorischen Aufwands bedarf. Das ist in der Tat so, hält sich aber in Grenzen, wenn man das GNU-RCS (Revision Control System) benutzt. Das RCS nämlich verwaltet beliebig viele Versionen eines Quelltextes platzsparend in einer einzigen Datei. Bei Bedarf läßt sich aus dieser Datei jede frühere Version extrahieren („aus-checken“), sofern sie zu einem früheren Zeitpunkt einmal „eingecheckt“ wurde.
Aus der Differenz ergibt sich die Summe
Von der einen zur nachfolgenden Version ändert sich ein Quelltext selten grundlegend. Die Differenzen sind, bezogen auf den Gesamtumfang der Quellen, meist recht gering. Es ist nicht erforderlich, stets den kompletten Quelltext aller verflossenen Versionen aufzubewahren, um diese Versionen bei Bedarf zurückgewinnen zu können. Statt dessen genügtes, wenn lediglich die Differenzen zwischen den einzelnen Quelltext-Revisionen verfügbar sind. Diesen Umstand nutzt das RCS aus, indem es in einer einzigen Datei alle Änderungen speichert, die sich bei der Quelltextbearbeitung ergeben haben.
Die RCS-Dateien, die die Grundlage für diese Art der Quelltextverwaltung bilden, besitzen einen charakteristischen Aufbau. Grundsätzlich enthält eine solche Datei die kompletten Informationen des Quelltextes in seiner allerersten Fassung. Zu allen weiteren Versionen enthält die RCS-Datei dann nur noch Angaben über die von einer Version nur nächsten erfolgten Änderungen. Diese Daten beschafft sich das RCS über den Aufruf des diff-Kommandos, das ebenfalls in einer GNU-Variante existiert. Unter Unix muß diff getrennt vom eigentlichen RCS-Paket installiert werden. Das Archiv mit der TOS-Version von RCS beinhaltet bereits alle anderen vom RCS benötigten Hilfsprogramme. Vorarbeiten sind hier also nicht erforderlich.
Das Einchecken
Wie gestaltet sich nun die Benutzung des RCS? Die vorhandenen Kommandos, die stets über eine Kommandozeile einzugeben sind, sind unter Unix und TOS identisch. Beim RCS unter TOS gibt es lediglich ein paar Besonderheiten zu beachten, die in erster Linie daraus resultieren, daß TOS keinen langen Dateinamen erlaubt und bis auf das Schreibschutz-Attribut keine für das RCS relevanten Zugriffsrechte unterstützt.
Das RCS besteht nicht nur aus einer einzigen P ogrammdatei, sondern zerfällt in mehrere Einzelprogramme, denen bestimmte Aufgaben zugeordnet sind. Zunächst kommt der Anwender mit dem Kommando c/in Kontakt, mit dem jeder Quelltext eingecheckt werden muß, bevor weitere Funktionen des RCS auf ihn angewendet werden können.
ci quellen.c
ci fordert den Benutzer auf, beim Einchecken der Datei einen Kommentar einzugeben. Wird ci auf die Datei quellen.c zum ersten Mal angewendet, befand sich die Datei bisher also noch nicht unter RCS-Kontrolle, sollte dieser Kommentar aus einer kurzen Beschreibung des Quelltextes bestehen. Bei Dateien, die bereits zu einem früheren Zeitpunkt eingecheckt wurden, bezieht sich der Kommentar auf die Änderungen im Vergleich zur letzten Version.
Beim erstmaligen Einchecken erzeugt ci unter Unix automatisch eine Datei mit dem Namen quellen.c, v. Sofern im aktuellen Verzeichnis ein Unterverzeichnis mit dem Namen RCS vorhanden ist, wird die Datei quellen.c.v in diesem Verzeichnis angelegt. Diese Datei, im folgenden auch RCS-Datei genannt, enthält eine Kopie der eingecheckten Datei sowie gewisse Statusinformationen, die das RCS für spätere Operationen benötigt. Nach dem Einchecken ist die Ursprungsdatei quellen.c relativ unwichtig geworden. Bei Bedarf lassen sich alle Informationen über quellen.c mit Hilfe des RCS aus quellen.c,v zurückgewinnen.
Die TOS-Version von c/ arbeitet ähnlich wie die Unix-Variante, allerdings sind unter TOS keine Dateinamen mit der Endung ,v erlaubt. Daher ist hier das unter Unix optionale Verzeichnis mit dem Namen RCS zwingend erforderlich, damit Namenkollisionen ausgeschlossen sind. Innerhalb dieses Verzeichnisses haben die RCS-kontrollierten Dateien keine spezielle Extension, sind also vom Namen her identisch mit den eigentlichen Quelltextdateien.
Aus neu mach alt
Sofern einmal ältere Versionen RCS-verwalteter Dateien benötigt werden, lassen sich diese mit co, dem Gegenstück zu ci, auschecken, co zieht die RCS-Dateien heran, um aus diesen die gewünschte Version zu extrahieren. Wie aber gibt man co zu verstehen, welche Version ausgecheckt werden soll?
Hier gibt es eine ganze Reihe von Möglichkeiten. Beim Einchecken einer Datei verteilt ci automatisch eine Versionsnummer, die automatisch inkrementiert wird und über deren Angabe das Auschecken erfolgen kann. Auch das Auschecken mit einer Datumsangabe ist möglich.
co -rl.2 quellen.c
erzeugt im aktuellen Verzeichnis aus der Datei quellen.c, v die Datei quellen.c in der Version 1.2.
co -dl2-January-1996,10:00 MET
checkt die Version der Datei quellen.c aus, die am 12.1.1996 um 10 Uhr gültig war.
Nun ist ein Datum oder eine Revisionsnummer nicht immer das ideale Kriterium, um einen bestimmten Quelltext zu identifizieren. Für den Menschen leichter zu handhaben sind symbolische Namen. Diese können durch das rcs-Kommando vergeben werden:
res -nNAME: quellen.c
ordnet der aktuellen Revision der Datei quellen.c den symbolischen Namen NAME zu. Anhand dieses Namens kann eine Revision später leicht identifiziert und mit co ausgecheckt werden.
Ein Blick in die Historie
Bei jedem Einchecken erwartet ci einen Kommentar, der die vorgenommenen Änderungen beschreibt. Diese Kommentare lassen sich zusammen mit einer Reihe von Zusatzinformationen mit dem rlogKommando abrufen.
riog quellen.c
zeigt die Kommentare zu allen Änderungen an, die an der Datei quellen.c vorgenommen wurden, seit sie erstmalig eingecheckt wurde. Auch die Zuordnung von symbolischen Namen wird dabei ersichtlich. Unter Unix läßt sich mit riog auch feststellen, welcher Benutzer welche Änderung durchgeführt hat. Unter TOS ist dies nicht ersichtlich, weil es hier keine eindeutige Benutzerkennung gibt, die mit dem login-Namen unter Unix vergleichbar wäre.
rlog macht außerdem eine Aussage darüber, ob eine Datei mit einem Lock versehen ist und wer in diesem Fall die Schreibberechtigung für die Datei besitzt. Im Gegensatz zum RCS unter TOS sorgt das RCS unter Unix nämlich dafür, daß eine Datei nur dann geändertwerden kann, wenn sie vorher mit einer entsprechenden Option ausgecheckt wurde. Hierzu gleich mehr.
rlog liefert lediglich allgemeine Informationen über die Historie einer Datei, macht jedoch keine Aussagen über die Änderungen, die von einer Revision zur nächsten durchgeführt wurden. Wer daran interessiert ist, kann sich des Kommandos rcsdiff bedienen:
rcsdiff quellen.c
zeigt alle Unterschiede des aktuellen, noch nicht eingecheckten Quelltextes zur letzten eingecheckten Version an. Auf diesem Weg kann man sich leicht einen Überblick über die aktuellen Änderungen verschaffen. Die von rcsdiff gelieferten Daten entsprechen übrigens dem, was ci beim Einchecken der aktuellen Quellen der RCS-Datei an Informationen hinzufügen würde. Denn in der RCS-Datei befinden sich ja gerade die Differenzen zwischen den einzelnen Quelltext-Revisionen.
Der Locking-Mechanismus
Das RCS läßt in der Standardeinstellung Änderungen an einer RCS-Datei nur dann zu, wenn diese Datei vorher mit der Option -/ ausgecheckt wurde. Derjenige, der die Datei auf diesem Weg ausgecheckt hat, erhält die exklusive Schreibberechtigung für die zugrundeliegende RCS-Datei. Dies bedeutet, daß niemand außer ihm diese Datei einchecken kann, solange der Lock nicht mit der Option -u wieder entfernt wurde. Das RCS File Locking verhindert also Kollisionen, die dann auftreten können, wenn mehrere Programmierer einen Quelltext gemeinsam bearbeiten. Ohne File Locking ist es leicht möglich, daß beim Einchecken Änderungen, die der Quelltext inzwischen durch einen weiteren Programmierer erfahren hat, überschrieben werden.
Falls es erforderlich ist, kann über das rcs-Kommando mit der Option -u ein Lock aufgehoben werden:
res -u quellen.c
setzt die exklusive Schreibberechtigung, wie sie von einem Benutzer beim Auschecken mit co -/ erhalten wurde, wieder zurück, res informiert den Anwender, der von dieser Änderungen betroffen ist, automatisch per e-Mail über diese Operation.
Verschmelzen, was zusammengehört
Der Vorteil des File Locking kann sich je nach Arbeitsweise durchaus auch als Nachteil erweisen. So kann es erwünscht sein, daß ein Quelltextgleichzeitig von verschiedenen Personen bearbeitet wird. Hin und wieder kommt es schließlich vor, daß zwei Programmierer eine Datei an voneinander unabhängigen Stellen bearbeiten. Hier widersprechen sich die vorgenommenen Änderungen in der Regel nicht, sondern ergänzen sich. In solchen Fällen erschwert das File Locking das parallele Arbeiten erheblich. Ganz auf File Locking zu verzichten ist wiederum mit Risiken verbunden. Das RCS bietet hier keine wirklich zufriedenstellende Lösung an. Immerhin ist das Programm rcsmerge dazu in der Lage, Quelltexte mit einem gemeinsamen Ursprung zu einer neuen Datei zu verschmelzen. Diese Datei schließt alle Änderungen ein, und falls es beim Merging keine Kollisionen gab, läßt sich der neue Quelltext anschließend sofort weiterverwenden. Besonders interessant wird das Mergen von Quelltexten dann, wenn es in Verbindung mit dem CVS (Concurrent Version System) erfolgt, das allerdings nur unter Unix verfügbar ist und nicht für TOS.
Vom RCS zum CVS
Das CVS-Paket stammt wie schon das RCS aus der GNU-Software-Schmiede. Ursprünglich handelte es sich um eine Sammlung von Unix Shell-Scripts, die die Verwaltung größerer Projekte mit dem RCS vereinfachen sollten. Inzwischen liegen diese Scripte als C-Programme vor. Die umfangreiche Dokumentation sollte man unbedingt studieren.
Das CVS verwaltet auf der Basis des RCS komplette Quelltextbäume und erlaubtes, Dateien nicht nur wie beim RCS einzeln auszuchecken, sondern zusammen mit anderen Dateien, die zum gleichen Projekt („Modul") gehören.
Mit dem CVS kann man selbst umfangreiche Projektbäume ähnlich einfach verwalten, wie es das RCS bei Einzeldateien erlaubt. Nahezu alle Operationen des CVS sind rekursiv ausgelegt. Im Gegensatz zum RCS arbeitet das CVS grundsätzlich ohne File Locking und unterstützt dafür aktiv das Quelltext-Merging mit rcsmerge.
Liest man sich die Dokumentation zum CVS durch, ist unverkennbar, daß diese Software primär dazu gedacht ist, große Projekte zu verwalten, die von mehreren Programmmierem gleichzeitig bearbeitet werden. Bei näherer Betrachtung zeigt sich allerdings, daß allein schon die Tatsache, einige Schwächen des RCS zu umgehen, die Beschäftigung mit dem CVS auch für kleinere Projekte lohnenswert erscheinen läßt.
Weitere Informationen
Das RCS bietet noch eine ganze Reihe von weiteren Möglichkeiten, die hier unerwähnt geblieben sind. Wie bei Unix-Programmen üblich, enthalten die manpages weiterführende Erklärüngen zu allen Programmen, die Bestandteil von RCS und CVS sind. Die TOS-Ver-sion des RCS beinhaltet sowohl die Unix-manpages als auch einfache ASCII-Textdateien gleichen Inhalts.
US
Software:
GNU RCS für TOS: Maus MS2
Quelltexte zum GNU RCS und CVS für Unix: ftp://ftp.uni-muenster.de/pub/gnu/ rcs-5.7.tar.gz
ftp://ftp.uni-muenster.de/pub/gnu/ cvs-1.7.tar.gz
Ausschnitt aus einer Historie des TOS-RCS, erhalten mit rlog: revision 1.13
date: 1996/03/02 11:43:44; authon user; state: Exp; lines: +6 -2
MOD tested with ACSI and TT SCSI
---------
revision 1.12
date: 1996/03/0118:02:02; authon user; state: Exp; lines: +8 -4
First Version with Support for 1024 BPS, tested with TT ACSI
revision 1.11
date: 1996/02/14 09:00:30; authon user; state: Exp; lines: +0 -0
HDDRIVER 4.62
Ein Beispiel für Differenzdaten, wie sie von rcsdiff geliefert werden:
RCS file: RCS/hddriver.s
retrieving revision 1.15
diff -rl.15 test.s
81c81
< resflag: dc.w 0 ;SCSI-Reset bei Fehler
----
> resflag: dc.w 1 ;SCSI-Reset bei Fehler
512c512
< btst #1,d0 ;Shift links?
----
> btst #0,d0 ;Shift rechte? 514d513
< addq.l #2,devptr ;erste Platte ignorieren
----