Transkript

1 47 4 Parallele Programmentwicklung mit CVS 4.1 Von Komponenten zu Software-Systemen In Kapitel 3 haben wir gezeigt, wie mit RCS Änderungen an einzelnen Dateien organisiert und koordiniert werden. In der Praxis besteht ein Software- System jedoch nicht nur aus einer einzelnen Komponente. Vielmehr ist es ein Grundprinzip des Software-Entwurfs, ein System in zahlreiche Komponenten aufzuteilen, die über ihre Schnittstelle (Deklaration) bestimmte wohldefinierte Dienste anbieten und in der Realisierung (Implementierung) dieser Dienste die Dienste anderer Komponenten in Anspruch nehmen. Ziel dieser Aufteilung ist es, die Auswirkungen einer Änderung auf die Realisierung einer Komponente zu beschränken. Die Realisierung kann sich ändern, aber solange die Schnittstelle unverändert bleibt, hat die Änderung keinen Einfluß auf den Rest des Software-Systems. Wird nun ein Software-System aus mehreren Komponenten versioniert, gilt es, zwei Ziele zu verfolgen: Konsistenz: Es muß stets gesichert sein, daß die in Anspruch genommenen Dienste einer Schnittstelle auch tatsächlich zur Verfügung gestellt werden. Das heißt: Wird eine Schnittstelle verändert, und bewirkt dies weitere Änderungen in weiteren Komponenten, so müssen diese Änderungen gekoppelt sein, so daß sie nicht unabhängig voneinander angewandt werden können. Flexibilität: Solange die Schnittstelle unverändert bleibt, muß es möglich sein, beliebige Versionen einer Komponente auszuwählen und so ein System passend für einen bestimmten Zweck oder eine bestimmte Umgebung zu konfigurieren. Versionierung eines Software-Systems Konsistenz von Konfigurationen Flexibilität von Konfigurationen Während Konsistenz eine absolut notwendige Qualitätsbedingung für Software-Systeme ist, gilt es, über die Konsistenz hinaus eine weitestmögli-

2 48 4 Parallele Programmentwicklung mit CVS che Flexibilität zu erreichen. Im Idealfall bleiben die Schnittstellen über die gesamte Lebensdauer eines Systems unverändert, so daß alle Revisionen aller Komponenten frei miteinander kombiniert werden können. Leider ist dieser Idealfall nicht immer gegeben: Die Entwicklung eines Software-Systems bedingt regelmäßig Änderungen an festgelegten Schnittstellen. Selbst wenn alle bisherigen Dienste unverändert bleiben und nur einige neue Dienste hinzukommen, bewirkt dies eine Inkonsistenz. Bietet etwa die Komponente A als Revision von A erweiterte Dienste an, kann die Komponente B, die diese erweiterten Dienste in Anspruch nimmt, nicht mehr mit A kombiniert werden. In der Praxis heißt so etwas dann»lauffähig auf Windows 2000 oder später«. SKM-Systeme bieten meist keine Mechanismen, um über die Konsistenz eines Software-Systems Aussagen zu treffen. Dafür können sie aber solche Aussagen ablegen und so beispielsweise als konsistent festgestellte Konfigurationen wiederherstellen. Voraussetzung hierfür ist, daß Konfigurationen eindeutig identifiziert werdenkönnen. InAbbildung 4.1sehenwir dreikomponenten, a.c, b.c und c.c, die jeweils in verschiedenen Revisionen auftreten. Abbildung 4.1 Gefädelte Darstellung von Konfigurationen. Jeder Faden faßt die berührten Versionen zu einer Konfiguration zusammen. Konfiguration 1 Konfiguration 2 Konfiguration a.c b.c c.c Faden Die Abbildung zeigt drei Konfigurationen; sie sind dargestellt durch einen vertikal verlaufenden Faden, der die in der Konfiguration enthaltenen Revisionen berührt. So besteht etwa die Konfiguration 2 aus a.c in der Revision , aus b.c in der Revision 1.4 sowieausc.c in der Revision 1.3. Diese Revisionen gilt es nun zu identifizieren, und zwar nach Möglichkeit

3 4.1 Von Komponenten zu Software-Systemen 49 bequemer als durch das pure Aufzählen von Komponenten und Revisionsnummern. Ein einfacher Mechanismus, wie er inrcs und ähnlichenskm-systemen benutzt wird, ist das Benennen von Konfigurationen. EinKonfigurationsname (engl. tag: Etikett) bezeichnet eine bestimmte Revision einer Komponente. Er kann für mehrere Komponenten benutzt werden und bezeichnet somit je eine Revision dieser Komponenten, eben eine Konfiguration. So können wir etwa in Abbildung 4.1 die Konfiguration 2 mit dem Namen conf2 versehen, und später, wollen wir die Konfiguration wiederherstellen, einfach beim check out statt einer Revisionsnummer oder eines Datums diesen Namen verwenden. In RCS funktioniert das so: Zum Vergeben eines Konfigurationsnamens benutzt man das Dienstprogramm rcs, das unter anderem mit der Option -nname:rev die Revision rev mit dem symbolischen Namen name identifiziert. Um nun die Konfiguration conf2 zu benennen, geben wir für jede Datei die entsprechende Revision an: $ rcs -nconf2: a.c RCS file: RCS/a.c,v $ rcs -nconf2:1.4 b.c RCS file: RCS/a.c,v $ rcs -nconf2:1.3 c.c RCS file: RCS/c.c,v $ _ Zum Wiederherstellen dieser Konfiguration reicht es, beim check out den Namen conf2 anzugeben: $ co -rconf2 a.c b.c c.c RCS/a.c,v --> a.c revision RCS/b.c,v --> b.c revision 1.4 RCS/c.c,v --> c.c revision 1.3 $ _ Das letzte Beispiel zeigt auch die Grenzen von Konfigurationsnamen: Während die Angabe von conf2 genügt, um die einzelnen Revisionen zu Benennen von Konfigurationen in RCS check out mit Konfigurationsname

4 50 4 Parallele Programmentwicklung mit CVS spezifizieren, müssen die Komponenten nach wie vor einzeln aufgezählt werden. Die tatsächliche Menge der Komponenten ist auch nicht der Revisionskontrolle unterworfen wird im Laufe der Entwicklung eine Komponente gelöscht, spiegelt sich dies in keiner der RCS-Dateien wider. Diesen Schritt von versionierten Komponenten hin zu versionierten Software-Systemen, oder prosaischer: von Dateien zu Dateibäumen, wollen wir in diesem Kapitel anhand des Werkzeuges CVS illustrieren. 4.2 Dateibäume versionieren mit CVS CVS check out aus CVS-Archiv cvs checkout Das Concurrent Versions System, kurz CVS, ist ein Werkzeug zum Versionieren von Dateibäumen. Im Gegensatz zu RCS werden Änderungen nicht nur in einzelnen Dateien erkannt; auch das Hinzufügen und Löschen von Dateien in Verzeichnissen wird berücksichtigt. Auf diese Art und Weise kann ein komplettes Software-Produkt, bestehend aus zahlreichen Dateien in mehreren Verzeichnissen, als eine Einheit versioniert werden. Wie auch RCS benutzt CVS ein zentrales Archiv, in dem alle Revisionen aller Quell-Dateien abgelegt werden. (Tatsächlich besteht das CVS-Archiv aus einer Menge von RCS-Archiven; siehe Abschnitt 4.3.) Und wie auch bei RCS wird das Archiv ausschließlich über eigene Befehle angesprochen. Typischerweise beginnt die Arbeit an einem Projekt damit, daß die Quel- len des Projekts aus dem CVS-Archiv in einen Arbeitsbereich kopiert werden. Dies geschieht mit dem CVS-Befehl checkout, der ein komplettes Ver- zeichnis mitsamt allen darin enthaltenen Dateien aus dem CVS-Archiv heraus ins aktuelle Verzeichnis kopiert. Die Befehle in CVS werden durch den Präfix cvs eingeleitet; der komplette Befehl lautet also cvs checkout, gefolgt vom Projektverzeichnis. Hier ein Beispiel: Entwicklerin Anke arbeitet an einem Projekt duden, das aus vier Dateien besteht. Das CVS-Archiv ist bereits eingerichtet. Mit checkout kopiert Anke den gesamten Inhalt des Projekts in ihr Arbeitsverzeichnis; wie beim RCS-Befehl co erhält sie die jeweils jüngste Revision des Hauptpfades. anke$ cvs checkout duden cvs checkout: Updating duden U duden/makefile U duden/duden.h U duden/grammatik.c U duden/woerter.c Das Verzeichnis duden enthält nun die Quelltexte aus dem CVS-Archiv. Außerdem enthält duden ein Verzeichnis namens CVS, dasvoncvs intern benutzt wird (und auf das wir in Abschnitt 4.3 zurückkommen).

5 4.2 Dateibäume versionieren mit CVS 51 anke$ cd duden anke$ ls CVS Makefile duden.h grammatik.c woerter.c Im Gegensatz zu RCS müssen in CVS Dateien nicht erst gesperrt werden, bevor sie bearbeitet werden können; Anke kann sofort mit ihrer Arbeit beginnen. Nach abgeschlossener Änderung kann Anke die neuen Revisionen ins CVS-Archiv zurückkopieren und somit anderen verfügbar machen. Dies geschieht durch den Befehl commit (engl. to commit: übergeben, anvertrau- en). Zunächst einmal kann Anke commit auf einzelne Dateien angewendet werden; es arbeitet dann ähnlich wie der RCS-Befehl ci. Nehmen wir an, Anke habe duden.h geändert und möchte die neue Version ins CVS-Archiv kopieren: Änderungen an CVS-Archiv übergeben cvs commit anke$ cvs commit duden.h Dies ruft Ankes Text-Editor auf, in dem sie einen Kommentar zur Änderung eingeben kann. Als Alternative kann Anke auch den Kommentar beim Aufruf von commit angeben. In beiden Fällen ist das Ergebnis, daß eine neue Revision im CVS-Archiv angelegt wird: anke$ cvs commit -m "Neu: NUMMERIERUNG" duden.h Checking in duden.h; /usr/share/cvs/duden/duden.h,v <-- duden.h new revision: 1.2; previous revision: 1.1 Mit CVS kann sich eine Änderung aber auch über mehrere Dateien erstrecken. Beim Aufruf von commit ohne Angabe von Dateien bezieht sich CVS nur auf diejenigen Dateien, die gegenüber der Version im Archiv geändert wurden. Hat Anke etwa grammatik.c und woerter.c geändert, erhält sie: anke$ cvs commit -m "Neue Deklination" cvs commit: Examining. cvs commit: Committing. Checking in grammatik.c; /usr/share/cvs/duden/grammatik.c,v <-- grammatik.c new revision: 1.2; previous revision: 1.1 Checking in woerter.c; /usr/share/cvs/duden/woerter.c,v <-- woerter.c new revision: 1.4; previous revision: 1.3

6 52 4 Parallele Programmentwicklung mit CVS Die so entstandene Konfiguration soll an einen Kunden ausgeliefert werden. Anke versieht sie mit einem Namen, damit sie später wiederhergestellt werden kann. In CVS geschieht dies mit dem tag-befehl, der die aktuelle Re- vision jeder Datei im Arbeitsverzeichnis mit einem Namen versieht. Anke wählt den Namen duden1-1 für die aktuelle Konfiguration: cvs tag anke$ cvs tag duden1-1 cvs tag: Tagging. T Makefile T duden.h T grammatik.c T woerter.c Projektdateien hinzufügen cvs add Möchte Anke die Konfiguration später wiederherstellen, kann sie beim checkout die Option»-r duden1-1«angeben: CVS bestimmt automatisch die benötigten Dateien und stellt die passenden Revisionen bereit. Möchte sie dann außerdem einen Fehler korrigieren, kann sie mit der zusätzlichen Option»-b«einen Nebenpfad erzeugen, in dem Fehler in duden1-1 unabhängig vom Hauptpfad korrigiert werden können. Im Moment bleibt Anke aber erst einmal im Hauptpfad. Nehmen wir an, Anke hat eine neue Datei ortho.c hinzugefügt. Das Hinzufügen von Quelldateien muß CVS speziell angemeldet werden. Dies geschieht mit dem add-befehl: anke$ cvs add ortho.c cvs add: scheduling file ortho.c for addition cvs add: use cvs commit to add this file permanently Beim nächsten commit wird ortho.c ins CVS-Archiv aufgenommen. anke$ cvs commit -m "Neu: ortho.c - Orthographie" cvs commit: Examining. cvs commit: Committing. RCS file: /usr/share/cvs/duden/ortho.c,v Checking in ortho.c; /usr/share/cvs/duden/ortho.c,v <-- ortho.c initial revision: 1.1 Anke könnte nun für diese Konfiguration einen neuen Namen vergeben; ein check out dieser Konfiguration würde automatisch ortho.c einschließen,

7 4.3 Wie CVS arbeitet 53 während in duden1-1 die Datei ortho.c noch nicht vorhanden war. Hier wird deutlich, wie CVS sichselbständigmerkt, welchedateienzu einerkonfiguration gehören und welche nicht. Zum Abschluß teilt Anke dem CVS-System mit, daß sie nun nicht mehr auf ihren Dateien arbeiten möchte. Hierfür gibt es in CVS den release- Befehl.release prüft, ob alle lokalen Änderungen auch wirklich ins CVS- Archiv übernommen wurden wenn nicht, wird eine Warnung ausgegeben. Wenn alle Änderungen übernommen wurden, kann mit der zusätzlichen Option»-d«der Arbeitsbereich gelöscht werden. Im Prinzip könnte der Arbeitsbereich auch ohne besondere CVS-Befehle gelöscht werden; CVS würde daran keinen Anstoß nehmen. Anke verwendet aber release wegen der zusätzlichen Sicherheit. cvs release anke$ cd.. anke$ cvs release -d duden You have [0] altered files in this repository. Are you sure you want to release directory duden : yes Damit ist Ankes duden-projekt wieder gelöscht. Zu einem späteren Zeitpunkt kann sie mit checkout duden ihre Arbeit wieder aufnehmen. 4.3 Wie CVS arbeitet Wenn in den vorangegangenen Beispielen die Meldungen von CVS denen von RCS ähneln, hat dies einen Grund: Für die Versionierung der einzelnen Dateien benutzt CVS das RCS-System. Wie in Kapitel 3 beschrieben, werden nur die Unterschiede zwischen den einzelnen Revisionen abgelegt und die gleichen Mechanismen zur Verwaltung von Haupt- und Nebenpfaden sowie Konfigurationsnamen benutzt. Was CVS von RCS unterscheidet, ist die Fähigkeit, auf kompletten Dateibäumen zu arbeiten. Dies wird von CVS so realisiert: Für jedes Projekt verwaltet CVS ein CVS-Archiv einen eigenen Dateibaum, der die gleichen Verzeichnisse und Unterverzeichnisse enthält wie das Original-Projekt. An die Stelle der Original-Dateien treten jedoch jeweils RCS-Dateien, wie in Abbildung 4.2 auf der nächsten Seite illustriert. Bei einem check out legt CVS zunächst die Verzeichnisse an, und zwar in der gleichen Struktur wie im CVS-Archiv. Anschließend werden über RCS anhand des Konfigurationsnamens oder des Datums die jeweiligen Revisionen konstruiert und in den Arbeitsbereich gestellt. CVS-Archiv

8 54 4 Parallele Programmentwicklung mit CVS Abbildung 4.2 check out aus einem CVS-Archiv. CVS kopiert die Verzeichnisse des CVS-Archivs ins Arbeitsverzeichnis und bestimmt für jede Datei die passende Revision. a.c checkout -r conf1 checkout -r conf2 a.c,v a.c c.c b.c,v c.c,v b.c c.c Arbeitsbereich CVS-Archiv Arbeitsbereich Ankes duden-projekt etwa wird von CVS als duden-verzeichnis abgelegt. Für jede der Dateien in ihrem Arbeitsverzeichnis findet Anke eine passende RCS-Datei: anke$ cd /usr/share/cvs/duden anke$ ls Makefile,v duden.h,v grammatik.c,v ortho.c,v woerter.c,v Hätte das duden-projekt noch Unterverzeichnisse, träten diese ebenfalls im CVS-Archiv auf; sie enthielten dann ebenfalls für jede Projekt-Datei eine RCS-Datei. Um ein commit korrekt auszuführen, muß CVS wissen, welche Revisionen im Arbeitsbereich stehen. Zu diesem Zweck verwaltet CVS im Arbeitsverzeichnis eine Datei CVS/Entries, in der die Nummern und check out-zeiten der Revisionen aufgezählt sind: anke$ cd anke$ cd duden anke$ more CVS/Entries /Makefile/ /Sat May 10 17:18: // /duden.h/1.2/sat May 10 17:34: // /grammatik.c/1.2/sat May 10 17:42: // /woerter.c/1.4/sat May 10 17:42: // D Diese Information benutzt CVS, um festzustellen, welche Dateien im Arbeitsverzeichnis der Versionskontrolle unterliegen und welche nicht.

9 4.4 Parallele Programmentwicklung 55 Im Laufe eines Projekts werden nicht nur Dateien hinzugefügt, sondern auch gelöscht, was CVS besonderen Aufwand bei der Verwaltung bereitet. Will Anke die Datei ortho.c wieder aus dem CVS-Archiv entfernen, so muß sie wie beim Hinzufügen dies CVS explizit mitteilen, und zwar mit einem Befehl namens remove. Wie auch add wirkt sich remove erst beim nächsten commit auf das CVS-Archiv aus. Projektdateien entfernen cvs remove anke$ rm ortho.c anke$ cvs remove ortho.c cvs remove: scheduling ortho2.c for removal cvs remove: use cvs commit to remove this file permanently anke$ cvs commit -m "ortho.c geloescht" cvs commit: Examining. cvs commit: Committing. Removing ortho.c; /usr/share/cvs/duden/ortho.c,v <-- ortho.c new revision: delete; previous revision: 1.1 Im CVS-Archiv werden gelöschte Dateien besonders verwaltet: Ihre RCS- Datei landet in einem speziellen Unterverzeichnis namens Attic (engl. Attic: Dachgeschoß). anke$ cd /usr/share/cvs/duden anke$ ls Attic Makefile,v duden.h,v grammatik.c,v woerter.c,v anke$ ls Attic ortho.c,v Durch diese spezielle Positionierung in Attic markiert CVS die Datei als»in der jüngsten Revision gelöscht«. Darüber hinaus verwendet CVS auch noch besondere Konfigurationsnamen, um gelöschte Revisionen eindeutig als solche zu kennzeichnen. 4.4 Parallele Programmentwicklung In unserem Beispiel aus Abschnitt 4.2 konnte Anke nach dem check out unmittelbar mit der Arbeit beginnen im Gegensatz zu RCS mußte sie nicht vor jeder Änderung die betroffenen Dateien durch eine Sperre für sich reservieren. Tatsächlichkennt CVS keinesperren dername CVS kommt gerade daher, daß CVS paralleles Arbeiten ausdrücklich zuläßt.

10 56 4 Parallele Programmentwicklung mit CVS Kooperationstrategie Änderungen abgleichen CVS basiert auf der Annahme, daß sich Entwickler untereinander absprechen und die Arbeit so aufteilen, daß sie sich nicht ins Gehege kommen und es deshalb ohnehin nur selten zu Konflikten kommt. Die Kooperationsstrategie von CVS wird deshalb auch optimistisch genannt im Gegensatz zur pessimistischen Kooperationsstrategie in RCS, die davon ausgeht, daß es zu Konflikten käme, würde RCS sie nicht mittels Sperren verhindern. Das parallele Arbeiten setzt allerdings voraus, daß Entwickler regelmäßig ihre Arbeitsbereiche mit dem CVS-Archiv abgleichen das heißt, Änderungen von anderen übernehmen sowie ggf. eigene Änderungen ins CVS-Archiv weitergeben. Findet kein Abgleich statt, wachsen die Unterschiede zwischen den einzelnen Arbeitsbereichen und damit auch die Wahrscheinlichkeit eines Konfliktes. Diesen Abgleichprozeß wollen wir an einem Beispiel erläutern. Nehmen wir an, Entwicklerin Petra ergänzt Anke bei der Arbeit am duden-projekt. Wie in Abbildung 4.3 gezeigt, haben sowohl Petra als auch Anke sich mit checkout eine aktuelle Revision des Projekts als Arbeitsumgebung eingerichtet. Abbildung 4.3 Zwei Arbeitsumgebungen aus einem CVS-Archiv check-out check-out Petras Arbeitsbereich CVS-Archiv Ankes Arbeitsbereich Nun führt Petra eine Änderung anduden.h durch. Mit commit kopiert sie dieneuerevisioninscvs-archiv, gezeigt in Abbildung 4.4. Abbildung 4.4 Übertragen von Änderungen aus einer Arbeitsumgebung commit Petras Arbeitsbereich CVS-Archiv Ankes Arbeitsbereich Anke hat ihrerseits ortho.c geändert und möchte die neue Revision ebenfalls ins CVS-Archiv übernehmen. Beim commit stellt aber CVS fest, daß

11 4.4 Parallele Programmentwicklung 57 Ankes duden.h nicht mehr mit der neuesten Revision übereinstimmt: Der commit-befehl schlägt fehl. Um dem commit-befehl gerecht zu werden, muß Anke erst einmal ihren Arbeitsbereich auf den neuesten Stand bringen. Hierfür benutzt sie einen besonderen CVS-Befehl namens update. Derupdate-Befehl bringt ein Arbeitsverzeichnis auf den neuesten Stand, indem alle Dateien, die seit dem check out im CVS-Archiv geändert wurden, erneut herauskopiert werden in unserem Fall die Datei duden.h mit Petras letzten Änderungen, wie in Abbildung 4.5 dargestellt. Arbeitsbereich auf neuesten Stand bringen cvs update update Abbildung 4.5 Übertragen von Änderungen in eine Arbeitsumgebung Petras Arbeitsbereich CVS-Archiv Ankes Arbeitsbereich Nachdem Anke überprüft hat, daß ihre lokale Änderung an ortho.c und Petras Änderungen in duden.h miteinander vereinbar sind, kann sie nun nachdem update ihre Änderungper commit ins CVS-Archiv propagieren. Petra würde dieseänderungdannbeiihremnächstenupdate inihreneigenen Arbeitsbereich übernehmen, gezeigt in Abbildung 4.6. update commit Abbildung 4.6 Weiteres Übertragen von Änderungen Petras Arbeitsbereich CVS-Archiv Ankes Arbeitsbereich Was aber passiert, wenn zwei Entwickler die gleiche Komponente zur gleichen Zeit geändert haben? Nehmen wir einmal an, Anke hätte in der Zwischenzeit ebenfalls duden.h geändert. Der update-befehl kann nicht einfach Ankes geänderte Fassung durch die aktuelle Revision des CVS-Archivs ersetzen, da dann ja Ankes Änderungen verlorengingen. Statt dessen integriert der update-befehl dann Ankes Änderungen und die jüngsten Änderungen aus dem CVS-Archiv, wie in Abschnitt 2.5 erläutert. Als Ursprungsfassung wird die Revision von Ankes letztem check out oder erfolgreichem

12 58 4 Parallele Programmentwicklung mit CVS commit zugrunde gelegt. Natürlich muß Anke, wie bei jedem anderen update auch, prüfen, ob ihre Arbeitsumgebung noch konsistent ist ob sich also Petras und ihre Änderungen vertragen. 4.5 Konflikte und Absprachen Konflikt Beobachten von Dateien cvs edit Haben Petra und Anke nicht nur dieselbe Datei, sondern auch dieselbe Stelle innerhalb der Datei verändert, kommt es zu einem Konflikt. CVS fügt dann beide Änderungen in die Datei ein und markiert die Konflikt-Stelle; der Konflikt muß dann von Hand aufgelöst werden. In der Praxis treten solche Konflikte jedoch selten auf. Das liegt daran, daß die Entwickler koordiniert vorgehen und ihre Arbeit untereinander absprechen. CVS bietet noch eine besondere Vorbeugemaßnahme, um die Absprache von Entwicklern sicherzustellen. Ein Entwickler kann dem CVS-System mitteilen, daß er eine einzelne Datei oder auch einen Dateibaum zu beobachten wünscht. Will ein anderer Entwickler eine Datei bearbeiten, kann er dies explizit anmelden. Dabei werden alle, die die Datei beobachten, automatisch benachrichtigt. Beide Funktionen, Anmelden und Beobachten, sind in CVS in dem edit-befehl zusammengefaßt. edit meldet die angegebene Datei zum Bearbeiten an; gleichzeitig wird der Benutzer als Beobachter der Datei eingetragen. Nehmen wir an, Anke habe die Datei duden.h mit checkout in ihren Arbeitsbereich kopiert. Anke teilt nun dem CVS-System explizit mit, daß sie duden.h bearbeiten möchte: anke$ cvs edit duden.h Anke ist nun Beobachterin von duden.h; gleichzeitig werden alle weiteren Beobachter informiert. Nehmen wir nun an, Petra möchte ebenfalls duden.h bearbeiten: petra$ cvs edit duden.h Ständiges Beobachten Bei dieser Aktion wird Anke nun automatisch benachrichtigt, daß Petra die Datei duden.h ebenfalls bearbeitet; sie kann nun ihre geplanten Änderungen mit Petra absprechen. Wenn Anke und Petra ihre Änderungen mit commit angewandt haben, werden sie von CVS automatisch als Beobachter ausgetragen; weitere Änderungen an duden.h gehen also an ihnen vorbei. Sie können sich allerdings bei CVS auch als ständige Beobachter eintragen; dann werden sie auch weiterhin über Änderungen informiert. Das gegenseitige Benachrichtigen macht nur Sinn, wenn auch alle Benutzerdenedit-Befehl verwenden. Dieswird mit dem watch-befehl erreicht.

13 4.6 Ergänzungen und Erweiterungen 59 watch markiert eine Datei oder ein Dateisystem in CVS als»zu beobachten«: Ist eine Datei mit watch markiert worden, gibt checkout sie im Arbeitsbereich zunächst nur zum Lesen frei; um sie verändern zu können, muß der Benutzer zuvor zwingend edit eingeben. Mit dem Mechanismus des Beobachtens bietet CVS einen Mittelweg zwischen der rein optimistischen und der rein pessimistischen Kooperationsstrategie: Entwickler werden zwar über potentielle Konflikte informiert, sind aber nicht gezwungen, auf das Ende der Sperre zu warten; statt dessen können sie sich über das weitere Vorgehen verständigen. 4.6 Ergänzungen und Erweiterungen Neben spezifischenprojekt-verzeichnissenenthältdas CVS-Archiv ein CVSeigenes»Projekt«namens CVSROOT. Inihmwerdenüber spezielle Dateien CVS-Ereignisse mit Benutzer-Aktionen verknüpft. Ein einfaches Beispiel ist die Verwaltung einer Protokolldatei, die bei jedem commit um einen neuen Eintrag ergänzt wird: Steht in der Datei loginfo ein Eintrag CVS-Anpassungen ˆduden $CVSROOT/CVSROOT/log.pl %s /irgendwo/dudenlog so wird bei jedem commit im duden-projekt das Programm log.pl aufgerufen, das den commit-kommentar (erstes Argument,»%s«) an die Datei /irgendwo/dudenlog (zweites Argument) anhängt. Die Datei dudenlog enthält dann in chronologischer Reihenfolge alle Änderungen, die jemals am duden-projekt durchgeführt wurden. Über die Dateien in CVSROOT sind weitreichende Anpassungen des CVS-Systems möglich. So könnte man Änderungen nicht nur in einer Datei protokollieren, sondern auch per an interessierte Entwickler schicken. Beim commit könnten Prüfprogramme aufgerufen werden, die sicherstellen, daß die neue Revision oder der Kommentar gewissen Standards genügt. Ebenso könnten bestimmte Dateien (etwa Binärdateien) aufgrund ihres Namens von der Versionierung ausgeschlossen werden. Änderungen in CVSROOT unterliegen natürlich ebenfalls der Versionskontrolle; mit cvs checkout CVSROOT wird eine Kopie von CVSROOT im eigenen Arbeitsverzeichnis erzeugt, und mit cvs commit werden die Änderungen ins CVS-Archiv zurückgespielt. Ebenso wie bei RCS gibt es zahlreiche graphische Benutzeroberflächen für CVS; Abbildung 4.7 auf der nächsten Seite etwa zeigt das tkcvs- Programm. Alle wichtigen CVS-Befehle können über einfachen Knopfdruck ausgewählt werden. Sehr bequem ist auch die CVS-Integration im EMACS-Editor unter dem Namen pcl-cvs, die andere EMACS-Pakete zum interaktiven Auflösen von Konflikten oder zum Hervorheben von Unterschieden gekonnt integriert.

14 60 4 Parallele Programmentwicklung mit CVS Abbildung 4.7 Eine graphische Benutzerschnittstelle zu CVS Bei CVS verfügt jeder Entwickler über eine komplette Kopie des Projekts, was bei großen Projekten viel Platz benötigt. Obwohl die Kosten des zusätzlichen Plattenplatzes nur den Bruchteil des Monatsgehalts eines Entwicklers ausmachen, ist diese Investition in der Praxis oft überraschend schwer durchzusetzen. Fortgeschrittene SKM-Systeme wie CLEARCASE lösen das Problem des Plattenplatzes, indem sie über ihr virtuelles Dateisystem jedem Entwickler die Illusion eines eigenen Arbeitsbereichs verschaffen, während tatsächlich jede Version einer Datei nur einmal abgelegt wird. Abschnitt 15.2 zeigtimrahmenderprogrammierumgebung SNiFF+ weitere Möglichkeiten, Arbeitsbereiche zu organisieren. Konzepte Ein SKM-System muß sowohl die Konsistenz von Konfigurationen sicherstellen als auch möglichst viel Flexibilität bei der Auswahl von Konfigurationen bieten. SKM-Systeme bieten in der Regel keine Mechanismen zur Erkennung von Konsistenz; durch das Benennen von Konfigurationen können konsistente Konfigurationen jedoch identifiziert und zu einem späteren Zeitpunkt wiederhergestellt werden.

15 4.6 Ergänzungen und Erweiterungen 61 Das CVS-System ermöglicht die Versionierung von kompletten Dateibäumen, indem CVS auch das Anlegen und Löschen von Dateien berücksichtigt. Ein CVS-Archiv ist strukturiert wie das Projekt selbst; jeder versionierten Datei ist ein RCS-Archiv zugeordnet. CVS realisiert eine optimistische Kooperationsstrategie, in der gleichzeitige Änderungen mehrerer Entwickler integriert werden. Übungen 1. Ihr Chef möchte weder Plattenplatz noch ein teures SKM-System anschaffen und schlägt vor, daß sich mehrere Entwickler einen gemeinsamen Arbeitsbereich teilen. Diskutieren Sie weniger konfliktträchtige Alternativen, die dennoch Platz sparen. 2. Strenggenommen versioniert CVS nur einzelne Dateien, einschließlich deren Existenz und Nicht-Existenz. Änderungen in der Projektstruktur, etwa das Hinzufügen oder Entfernen von Verzeichnissen, werden nicht versioniert; CVS löscht einfach Verzeichnisse, sobald sie keine Datei mehr enthalten, und erstellt sie neu, sobald sie wenigstens eine Datei enthalten. Auch Änderungen in Eigenschaften von Dateien, wie etwa Zugriffsrechte, werden nicht versioniert. Welche Konsequenzen hat dies in der Praxis? 3. Die Rechtschreibreform macht auch vor Dateinamen nicht halt: Sie sollen die Datei numerierung.c in nummerierung.c umbenennen. Hierfür gibt es zwei Vorschläge: Kollege Müller schlägtvor, eine neue Datei nummerierung.c anzulegen, dort die letzte Revision von numerierung.c abzulegen und die alte Datei dann zu löschen:»auf diese Art und Weise können wir die alte Konfiguration exakt wiederherstellen.«kollege Meier hingegen meint, Sie sollten im CVS-Archiv die RCS-Datei numerierung.c,v in nummerierung.c,v umbenennen:»nur so bleibt die Revisionsgeschichte erhalten.«wofür entscheiden Sie sich? 4. Für bestimmte Anwendungen ist eine rein textbasierte Integration wenig sinnvoll: So benötigen etwa Dokumente einer Textverarbeitung oder CAD-Dateien besondere Integrationswerkzeuge. Worauf müssen Sie achten, wenn ein solches Integrationswerkzeug nicht verfügbar sein sollte? Denken Sie auch an die Kooperationsstrategie!

16 62 4 Parallele Programmentwicklung mit CVS 5. Ihr Kollege hat Änderungen gemacht und ins CVS-Archiv gesteckt, die verhinderten, daß sich Ihr Projekt überhaupt übersetzen ließ und das am Tag, bevor er in Urlaub ging. Um solche Situationen in Zukunft zu vermeiden, schlägt Ihr Chef vor, daß bei jedem commit automatisch ein Prüfprogramm gestartet wird, das Ihr Projekt mit den vorgeschlagenen Änderungen automatisch übersetzt und einige Tests durchführt. Jedes commit würde damit etwa 10 Minuten Zeit benötigen. Diskutieren Sie Vor- und Nachteile. Bibliographische Hinweise CVS wurde erstmals von Berliner (1990) vorgestellt; in der Urfassung war CVS noch über Shell-Skripte realisiert. In der Zwischenzeit ist CVS kontinuierlich weiterentwickelt worden und ist heute ein weitverbreitetes System für einfache SKM-Aufgaben in mittelgroßen Projekten. CVS ist frei erhältlich; Beratung und Unterstützung zu CVS werden von diversen Unternehmen kommerziell angeboten. Die Arbeit an diesem Buch wurde mit CVS koordiniert. Das erste System, das ein virtuelles Dateisystem zur Versionierung bereitstellte, war das SUN Network Software Environment (NSE), beschrieben von Courington (1989). Im virtuellen Dateisystem von NSE sind Arbeitsbereiche als Sichten auf ein zentrales Archiv realisiert. Erst, wenn ein Entwickler in seinem Arbeitsbereich eine Datei ändert, wird eine physikalische Kopie angelegt. Für den Entwickler ist dieses copy-on-write transparent; NSE sorgt automatisch dafür, daß gemeinsame Teile über alle Arbeitsbereiche zwischen mehreren Entwicklern geteilt werden. In NSE wurde die optimistische Koordinierungsstrategie unter dem Begriff der langen Transaktion eingeführt. Die Analogie zum Transaktionsbegriff in Datenbanksystemen gilt heute als irreführend, da es in Datenbanksystemen keine Entsprechung für den Abgleich von Änderungen gibt. Das Zusammenspiel von Konsistenz und Flexibilität beim Konfigurieren von Software-Systemen ist eine alte Forderung von SKM-Anwendern. Jüngere Forschungsansätze unterscheiden intensionale Versionierung, in der das SKM-System die Konfiguration nach Inhalten zusammenstellt d.h. gemäß den Wünschen des Anwenders und die hier behandelte extensionale Versionierung, in der die Versionen explizit aufgezählt werden.bei intensionaler Versionierung könnenänderungen frei kombiniert werden; Systeme werden über deren Eigenschaften konfiguriert und konstruiert. Über einschränkende Bedingungen (etwa: Änderung A und Änderung B schließensichgegenseitig aus) kann das SKM-System die Konsistenz der entstehenden Konfiguration sicherstellen.

17 4.6 Ergänzungen und Erweiterungen 63 Ein erstes intensionales SKM-System ist EPOS, beschrieben von Gulla et al. (1991): Es erlaubt die beliebige Kombination von Änderungen über die Auswahl von Optionen. Für das ICE-System, in dem Intentionen mit Hilfe der Feature-Logik ausgedrückt werden, wiesen Zeller und Snelting (1997) nach, daß die intensionale Versionierung über eine geschickte Wahl der einschränkenden Bedingungen alle bekannten Versionierungsmodelle umfaßt. Nebeneffekt der intensionalen Versionierung ist übrigens, daß alle Aspekte der Versionierung, insbesondere Revisionen und Varianten, gleich behandelt werden. Die Konsistenzsicherung spielt ebenfalls eine große Rolle bei der dynamischen Konfiguration, bei der erst zur Laufzeit über die Konsistenz einer Konfiguration entschieden wird. Dieses aktuelle Forschungsthema wird unter anderem von Schmerl und Marlin (1995) sowie Warren und Sommerville (1995) behandelt. Weitere Werkzeuge zum Konfigurationsmanagement Neben den in diesem Buch beschriebenen frei erhältlichen Werkzeugen RCS und CVS gibt es zahlreiche weitere, meist kommerzielle Werkzeuge zum Software-Konfigurationsmanagement. In der folgenden Liste haben wir eine Auswahl zusammengestellt. Die Firma Open Avenue (früher Cyclic Software) bietet CVS mit kommerzieller Unterstützung an. CLEARCASE von Rational ist eins der leistungsfähigsten SKM- Systeme auf dem Markt. Sein virtuelles Dateisystem erlaubt direkten Zugriff auf beliebige Versionen; CLEARCASE ermöglicht außerdem, den Entwicklungs- und Änderungsprozeß anhand von individuellen Aktivitäten zu organisieren (sogenanntes unified change management). CONTINUUS/CM von Continuus legt ebenfalls besonderen Wert auf den Entwicklungs- und Änderungsprozeß, der sich hier wie bei kaum einem anderen Werkzeug organisieren läßt. Die eigentliche Versionskontrolle tritt demgegenüber in den Hintergrund, bietet aber alles, was man braucht. PERFORCE von Perforce Software ist ein außerordentlich schnelles und leicht zu bedienendes System zur Versionskontrolle. Das von Seiwald (1996) entwickelte Verfahren des Inter-File-Branching erlaubt einen besonders bequemen Zugriff auf Varianten. Wie auch CVS ermöglicht PERFORCE das Arbeiten auf lokalen Kopien.

18 64 4 Parallele Programmentwicklung mit CVS PVCS von Merant und Synergex bietet einfache Versionskontrolle, die sich gut in eine Vielzahl von Plattformen integrieren läßt. AEGIS ist ein frei erhältliches SKM-System, dessen Entwicklungsprozeß Konsistenzprüfungen fordert: Eine Änderung kann nur dann veröffentlicht werden, wenn Programmkonstruktion, Tests und ggf. Code-Inspektionen erfolgreich abgeschlossen wurden. Auch RAZOR von Tower Software bietet einen ausgefeilten Änderungs- und Entwicklungsprozeß, basierend auf einem grundlegendem Versionskontrollsystem wie RCS oder SCCS. Nur für WINDOWS erhältlich. SOURCE INTEGRITY von MKS erlaubt ebenfalls das Einrichten und Anpassen eines individuellen Änderungs- und Entwicklungsprozesses. Nur auf WINDOWS. VOODOO von Uni Software Plus ist ein SKM-System für MacOS, das sich durch orthogonale Versionierung auszeichnet. Mit VOODOO ist es besonders einfach, eine Vielzahl von Varianten zu verwalten, wie in Reichenberger (1995) beschrieben. VISUAL SOURCE SAFE von Microsoft bietet grundlegende Funktionalität der Versionskontrolle (etwa auf RCS-Niveau) unter einer WINDOWS-Oberfläche. In der Vergangenheit soll es häufiger zu Problemen der Datenintegrität gekommen sein; Käufer sollten sich nach Erfahrungsberichten in Internet-Foren umsehen. Die Firma Mainsoft bietet VISUAL SOURCE SAFE auch für UNIX an. Weitere Informationen und aktuelle WWW-Verweise zu all diesen Werkzeugen finden Sie unter:

19 65 Praktische Übungen I In dieser Übung können Sie einfache Programmpflege mit CVS betreiben. Hierfür müssen Sie zunächst CVS einrichten. Vorbereitung 1. In ftp://ftp.gnu.org/pub/gnu/hello/ finden Sie das GNU Hello-Programm z.b. als hello-1.3.tar.gz. Kopieren Sie es in eins Ihrer Verzeichnisse, und packen Sie es aus mit: $ gunzip hello-1.3.tar.gz $ tar xvf hello-1.3.tar $ cd hello Nun sollen Sie GNU Hello unter Versionskontrolle mit CVS stellen. Wir gehen hier Schritt für Schritt vor: (a) Wählen Sie ein Verzeichnis aus, in dem das CVS-Archiv abgelegt werden soll (etwa $HOME/CVS), und setzen Sie die Variable CVSROOT entsprechend. Mit sh geht das so: $ CVSROOT=$HOME/CVS; export CVSROOT Wenn Sie csh als Shell benutzen: % setenv CVSROOT $HOME/CVS (b) Richten Sie CVS ein: $ cvs init (c) Stellen Sie das Paket unter CVS-Kontrolle: $ cvs import -m "Import GNU Hello 1.3" \ hello GNU HELLO 1 3 (d) Nun können Sie die Original-Quellen wieder löschen. $ cd.. $ rm -fr hello-1.3 (e) Um mit dem CVS-kontrollierten GNU Hello zu arbeiten, müssen Sie GNU Hello zunächst auschecken:

20 66 Praktische Übungen I $ cvs checkout hello Im Verzeichnis hello (dem Arbeitsverzeichnis) finden Sie nun alle GNU Hello-Quellen unter CVS-Kontrolle. 3. In zukünftigen CVS-Sitzungen mit hello müssen Sie CVSROOT nicht erneut setzen. Statt dessen können Sie unmittelbar in Ihrem Arbeitsverzeichnis weiterarbeiten. Wenn Sie jedoch ein neues Projekt beginnen, können Sie für dieses neue Projekt analog zu Punkt 2 verfahren. 4. Zum Testen von GNU Hello gehen Sie wie folgt vor: Übungen (a) Lesen Sie die Anweisungen in README und INSTALL, und übersetzen Sie das Hello-Programm für Ihren Rechner: $./configure $ make (b) Führen Sie das Hello-Programm aus: $./hello 1. Sie sollen die Ausgabe von GNU Hello ins Deutsche übersetzen. Betrachten Sie die Datei hello.c, und ändern Sie die Ausgabe passend ab. (Sie müssen kein C können, um diese Änderung durchzuführen.) Prüfen Sie das Ergebnis, indem Sie GNU Hello neu übersetzen und ausführen. 2. Bestimmen Sie mit cvs diff die von Ihnen eingefügten Unterschiede zwischen der Original-Version und Ihrer eingedeutschten Variante. Untersuchen Sie die Effekte der verschiedenen DIFF-Optionen. 3. Die von Ihnen durchgeführten Änderungen sollen Sie nun ins CVS- Archiv propagieren. Benutzen Sie dafür cvs commit. 4. Erstellen Sie nun einen Patchfür GNU Hello. Hierfür benötigen Sie die von DIFF erzeugten Unterschiede, und zwar über mehrere Revisionen hinweg. Hierfür können Sie ebenfalls cvs diff einsetzen. Nennen Sie Ihren Patch hello-de.patch. 5. Prüfen Sie, ob Ihr Patch funktioniert, indem Sie ihn auf das erneut ausgepackte GNU Hello-Paket anwenden. Was passiert, wenn Sie denselben Patch zweimal anwenden?

21 Praktische Übungen I Erstellen Sie einen alternativen Patch hello-fr.patch, dergnu Hello ins Französische (»Bonjour, monde«) übersetzt. Was passiert, wenn Sie beide Patches anwenden wollen? 7. Erstellen Sie einen Patch, der in der deutschen Version die Datei hello.c in hallo.c umbenennt: (a) Benennen Sie hello.c in hallo.c um. Mit cvs add kennzeichnen Sie die hinzugefügte Datei, mit cvs remove die gelöschte Datei. Weitere Hinweise finden Sie unter»moving and renaming files«im CVS-Handbuch. (b) Beim Anwenden des Patches müssen Sie sicherstellen, daß leere Dateien gelöscht werden. Siehe»Removing empty files«im PATCH-Handbuch. 8. Legen Sie eine Datei.cvsignore an, damit die von configure erzeugten, systemspezifischen Dateien von CVS ignoriert werden. Weitere Hinweise finden Sie unter»ignoring files via cvsignore«im CVS-Handbuch.