2 Was ist Versionsverwaltung - Institut für Wirtschaftsinformatik

Westfälische Wilhelms- Universität Münster
Ausarbeitung
Werkzeuge zum Versions- und Variantenmanagement:
CVS/Subversion vs. ClearCase
Im Rahmen des Seminars
Skiseminar: Variantenmanagement
Lars Fischer
Themensteller: Prof. Dr. Herbert Kuchen
Betreuer: Prof. Dr. Herbert Kuchen
Institut für Wirtschaftsinformatik
Praktische Informatik in der Wirtschaft
Inhaltsverzeichnis
Inhaltsverzeichnis
1 Einleitung...................................................................................................................... 1
2 Anforderungen ............................................................................................................. 1
3 Werkzeuge und Funktionsweisen............................................................................... 2
3.1 Werkzeuge ............................................................................................................ 3
3.1.1 CVS .................................................................................................................. 3
3.1.2 Subversion ....................................................................................................... 3
3.1.3 ClearCase......................................................................................................... 3
3.2 Bestandteile und Funktionen .............................................................................. 4
3.2.1 Repository........................................................................................................ 4
3.2.2 Arbeitsbereich und Übertragung .................................................................. 6
3.2.3 Sperren und Merging ................................................................................... 10
3.2.4 Versionen, Revisionen .................................................................................. 16
3.2.5 Tags ................................................................................................................ 17
3.2.6 Branching ...................................................................................................... 19
4 Zusammenfassung und Ausblick.............................................................................. 21
1 Einleitung
1 Einleitung
Im Rahmen der Seminarreihe Variantenmanagement ist es das Ziel dieser Arbeit einen
Einblick in das Variantenmanagement in der Informatik, genauer gesagt, im Bereich der
Softwareentwicklung zu geben.
Variantenmanagement wird also nicht nur in der Betriebswirtschaftslehre benutzt, sondern auch im Bereich der Informatik. Die Bezeichnung ändert sich allerdings. Statt von
Variantenmanagement redet man nun von Versionsverwaltung.
In der Literatur existieren verschiedene Definitionen. Eine passende ist die von Jennifer
Vespermann. Sie beschreibt Versionsverwaltung als den Prozess vom Aufzeichnen und
Erhalten von Änderungen der Daten in einem Projekt [EsCVS03].
Was damit im Detail gemeint ist, stellt den Inhalt der Seminararbeit dar. Im weiteren
Verlauf werde ich zunächst auf einige Anforderungen an ein Versionsverwaltungssystem eingehen, bevor dann die einzelnen Bestandteile, ihre Funktionsweisen und die entsprechenden Werkzeuge vorgestellt werden.
2 Anforderungen
Aus der Definition ist also zu erkennen, dass ein Versionsverwaltungssystem mit Projektdaten arbeitet und den Prozess der Softwareentwicklung unterstützen soll. Diese
allgemeinen Anforderungen sollen im Folgenden auf verschiedene Erfolgsfaktoren herunter gebrochen werden und die einzelnen funktionellen Forderungen an das Versionsverwaltungssystem beschrieben werden.
Datenintegrität
Ein Versionsverwaltungssystem soll die Integrität aller Projektdaten sicherstellen. Zum
einen sollen Daten nicht verloren gehen, zum anderen sollen fehlerhafte Veränderungen
rückgängig gemacht werden können.
Produktivität
Ein Erfolgsfaktor von Softwareprojekten ist die Produktivität. Es soll in möglichst kurzer Zeit möglichst ein perfektes Produkt entwickelt werden. Die soll durch ein Versionsverwaltungssystem unterstützt werden. Die Möglichkeit zur Produktivitätssteigerung
tritt in vielen Bereichen eines Softwareprojektes auf. Paralleles Arbeiten auf den glei-1-
2 Anforderungen
chen Daten, Verhindern von „doppelter“ Arbeit, Vereinfachung des Testens oder die
Wiederherstellung von altem Code nach einer Fehlentwicklung sind einige Beispiele.
Zurechenbarkeit
Es besteht die Anforderung, klar erkennen zu können, wer zu welchem Zeitpunkt was in
den Projektdaten verändert hat. Zum einen um den Mitarbeiter für schwerwiegende
Fehler verantwortlich machen zu können, zum anderen um die Kommunikation unter
Mitarbeitern zu erleichtern.
Entwicklungszweige
Während der Entwicklung einer Software kann die Situation auftreten, dass verschiedene Teams der Mitarbeiter verschiedene Ziele erreichen wollen, z.B. Weiterbearbeitung
des Codes gegenüber dem Erstellen einer Testversion für den Kunden. Sinnvoll ist dann
die Trennung der zu verrichtenden Arbeit, jedes Team arbeitet an getrenntem Code zur
Erreichung des Ziels. Diese getrennte Bearbeitung soll unterstützt werden.
Protokollierung
Weiterhin sollen Änderungen nicht einfach nur im Code ersichtlich sein, sondern die
Mitarbeiter sollen wissen, warum und was ein anderer Kollege geändert hat. Dies fördert das Verständnis und erleichtert die weitere Entwicklung. Zu diesem Zweck sollen
Änderungen mit Kommentaren versehen werden können.
Verteilte Arbeit
Aufgrund der technologischen Entwicklung werden viele Projekte nicht an einem Ort
ausgeführt, sondern sind eher durch räumliche, bzw. örtliche Trennung gekennzeichnet.
Ein Versionsverwaltungssystem soll trotz dieser Trennung die gemeinschaftliche Arbeit
unterstützen.
3 Werkzeuge und Funktionsweisen
Nach der bisherigen allgemeinen Einführung in die Versionsverwaltung wird in diesem
Kapitel detaillierter auf die wichtigsten Funktionsbereiche eines solchen Systems eingegangen und diese anhand von Beispielen in verschiedenen Werkzeugen vorgestellt.
-2-
3.1 Werkzeuge
3.1 Werkzeuge
Bei den betrachteten Werkzeugen handelt es sich um das Concurrent Version System
(CVS), Subversion und ClearCase. Es existieren neben diesen Programmen noch eine
Reihe weiterer, deren Betrachtung hier aber keine Rolle spielt.
3.1.1 CVS
Das Concurrent Version System, kurz CVS, ist ein Programm zur Versionsverwaltung
von Dateien, welches hauptsächlich in der Softwareentwicklung angewendet wird, also
in dem hier behandelten Kontext. Grundsätzlich ist es ein reines KommandozeilenProgramm. Es ist für alle Betriebssysteme entwickelt und geeignet. Zudem sind grafische Oberflächen für die verschiedenen Systeme erhältlich.
Eine wichtige Eigenschaft von CVS ist der Open-Source-Gedanke. Das Programm benötigt keine Lizenzen und ist frei im Internet erhältlich.
Historisch gesehen ist CVS eine Weiterentwicklung eines älteren Systems, dem Revision Control System. Auf die Funktionen und Arbeitsweise von CVS wird in den Kapiteln 3.2 bis 3.7 genauer eingegangen.
3.1.2 Subversion
Wie auch das eben beschriebene CVS ist Subversion ein Open-Source-Programm. Häufig wird es auch als Nachfolger von CVS gehandelt und ersetzt dieses allmählich. Auch
Subversion ist für alle Betriebssysteme geeignet und läuft grundsätzlich auf Kommandozeilen-Ebene. Allerdings sind auch hier zahlreiche grafische Oberflächen entwickelt
worden.
Es behebt einige Schwächen von CVS und ist von der Bedienung ähnlich gehalten.
Grundsätzlich handelt es sich bei Subversion allerdings um ein eigenes Projekt, welches
erst im Februar 2004 die erste stabile Version veröffentlichte.
Die Unterschiede und Gemeinsamkeiten zu CVS werden in den weiteren Kapiteln deutlich gemacht.
3.1.3 ClearCase
-3-
3.1.3 ClearCase
Das Versionsverwaltungssystem ClearCase ist in der Reihe der Rational Software von
IBM erschienen. Es handelt sich um proprietäre Software, die eben von IBM vertrieben
wird. ClearCase wird vornehmlich in großen Softwareprojekten verwendet, was unter
anderem an den Kosten für die Lizenzen liegt, die sehr hoch sind. Weiterhin ist ClearCase hauptsächlich für Windows ausgelegt, ansonsten läuft es nur auf einigen ausgewählten UNIX-Systemen, z.B. nicht auf MacOS X.
Im Unterschied zu den beiden anderen Systemen ist eine grafische Oberfläche direkter
Bestandteil des Programms, viele Funktionen lassen sich sogar auf Windows-Systemen
über den Datei-Explorer bedienen. Allerdings besteht auch die Möglichkeit über Kommandozeilen Befehle auszuführen.
ClearCase ist im Wesentlichen deutlich komplexer, aber auch leistungsfähiger als CVS
und Subversion. Aus diesem Grund wird ClearCase auch vor allem in großen Projekten
angewendet.
3.2 Bestandteile und Funktionen
Der Inhalt dieses Kapitels besteht aus der Beschreibung der einzelnen Bestandteile der
Versionsverwaltungssysteme und wie diese zusammen arbeiten und vom Anwender
kontrolliert und genutzt werden können.
3.2.1 Repository
Das Repository ist ein elementarer Bestandteil eines Versionsverwaltungssystems. Es
wird auch Kern des Systems bezeichnet. Es ist ein zentraler Speicher, in welchem alle
Projektdaten im Lebenszyklus eines Softwareproduktes gespeichert werden. Zunächst
müssen aber die zu speichernden Daten definiert sein. Dies ist nicht nur der Quellcode,
sondern alle Daten, die benötigt werden, um eine lauffähige Version der Applikation
herstellen zu können [PVC03, S.9].
Grundsätzlich werden die Daten in einem Dateisystembaum gespeichert. Es besteht eine
Hierarchie von Verzeichnissen und Dateien. Das Repository ähnelt also einem normalen
Dateiserver. Es biete aber eine deutlich höhere Funktionalität. Denn es werden nicht nur
die Daten gespeichert, sondern auch jede einzelne Änderung in der Verzeichnisstruktur,
bzw. der Dateien. Die Art der Speicherung ist verschieden. Manche Systeme verwenden
eine Datenbank, manche spezielle Dateiformate und andere Kombinationen aus beidem.
-4-
3.2.1 Repository
Stellt man sich das Repository nun als Server vor und die Entwickler als Clients, entsteht eine bekannte Struktur. Die Clients haben die Möglichkeit Daten vom Server zu
lesen und auf ihn zu übertragen. Neben den aktuellen Daten können auch ältere Versionen der Daten abgerufen werden. Denn jede Revision jeder Datei verbleibt im Repository. Allerdings werden in den meisten Versionsverwaltungssystemen nicht alle Revisionen einer Datei komplett gespeichert, denn dies würde einen sehr hohen Speicherbedarf
bedeuteten. Um dies zu vermeiden, vergleicht das System die ältere und neue Revision
einer Datei und speichert nur die Änderungen ab. So wird viel Speicherplatz gespart.
Das Repository ist immer angebunden an ein Netzwerk. Dies kann ein internes Netzwerk innerhalb einer Unternehmung sein oder ein lokales auf einem Rechner, aber auch
das Internet bei größeren örtlichen Entfernungen.
Das Repository spielt also eine wichtige Rolle. Ergo ist die Sicherheit ein Thema. Das
Repository sollte auf einem sicheren und zuverlässigen Rechner gespeichert sein. Der
Verlust wäre für ein Softwareprojekt fatal [PVC03, S.8]
In dem Versionsverwaltungssystem CVS ist das Repository eine Art Dateiserver mit
einem Verzeichnisbaum. Es existiert ein Verzeichnis für die allgemeine Konfiguration
und ein Verzeichnis für jedes Projekt. Jede Datei des Projektes wird nun in dem zugehörigen Verzeichnis gespeichert. Allerdings nicht nur die Datei, sondern mit ihr noch Zusatzinformationen wie Unterschiede zu vorherigen Versionen, Zeitpunkt der Änderung,
Kommentar vom Entwickler, dem Namen des Entwicklers und der Versionsnummer.
Das Format dieser Datei wurde übernommen aus dem Vorgänger RCS.
CVS arbeitet folgendermaßen: In der praktischen Anwendung muss das Repository
zunächst gebildet werden:
$ cvs –d C:\sandbox init
Nun existiert das Repository, aber noch kein Projekt. Dazu müssen nun Dateien in das
Repository eingefügt werden. In einem Verzeichnis „cvs“ liegen zwei Textdateien Farben.txt und Zahlen.txt. Dies werden nun in das Repository geladen:
$ cvs> cvs –d C:\Sandbox import –m „“ Lala
CVS - Antwort:
N Lala/Farben.txt
N Lala/Uahlen.txt
No conflicts created by this import
Damit sind die Dateien im Repository und ich habe das Projekt Lala genannt.
In dem Versionsverwaltungssystem Subversion ist der grundlegende Unterschied, dass
das Repository zum einen in einer Berkley Datenbank, aber auch direkt im Dateisystem
-5-
3.2.1 Repository
gespeichert werden kann [WIKIS]. Ansonsten laufen die Befehle ähnlich ab. Sie haben
nur einen anderen Namen. So wir das Repository mit dem Befehl
$ svnadmin create Pfad/zum/Repository angelegt
angelegt und importiert wird über die Funktion
$ svn import /daten/ file:///c:/Pfad/zum/Repository
ClearCase nennt sein Repository VOB (Versioned Object Base). In ihm speichert es alle
Elemente eines Projektes. Bei sehr großen Projekten ist es auch möglich und üblich
mehrere VOB`s anzulegen [IBM03, S.2]. Die Einrichtung in ClearCase erfolgt über den
ClearCase Explorer oder den entsprechenden Befehl auf Kommandozeilen - Ebene.
3.2.2 Arbeitsbereich und Übertragung
Wie eben beschrieben, liegen die Daten zentral im Repository. Dort sind sie aber nur
gespeichert. Sie können zwar abgerufen, aber es kann nicht auf ihnen gearbeitet werden.
Für die Änderung der Daten benötigen die Entwickler eine Kopie auf ihrem Rechner,
die so genannte Arbeitskopie in ihrem Arbeitsbereich. Diese Arbeitskopie muss nicht
sämtliche Projektdaten enthalten. Es besteht auch die Möglichkeit nur eine Teilmenge
auf den eigenen Rechner zu kopieren.
Extrem wichtig ist nun natürlich die Frage, wie die Kommunikation zwischen dem Arbeitsbereich und dem Repository abläuft. Grundsätzlich gibt es nur zwei Richtungen.
Entweder ein Entwickler will die aktuellen Daten aus dem Repository in seinen Arbeitsbereich kopieren oder er möchte seine Änderungen in das Repository einstellen.
Der typische Verlauf der Kommunikation hat als Anfang immer die Initiative des Entwicklers. Um an dem gewünschten Code arbeiten zu können, benötigt er die aktuelle
Revision der Datei in seinem Arbeitsbereich. Dieser Kopiervorgang wird als „check
out“ bezeichnet. Danach kann der Mitarbeiter an dem Code arbeiten. Hat er seine Änderungen vollendet, muss er diese in das Repository einstellen. Dieser Vorgang wird als
„commit“ oder „check in“ bezeichnet.
Weiterhin gibt es noch die Möglichkeit des Updates. Mit dieser Funktion kann man sich
während des Bearbeitens von Dateien die aktuellsten Versionen aus dem Repository
laden. Die Ähnlichkeit zu „check out“ ist unverkennbar.
So einfach wie dies alles klingt ist es in der Realität aber leider nicht. Wenn ein Versionsverwaltungssystem eingesetzt wird, arbeiten meist mehrere Entwickler an einem
Projekt und somit auf den gleichen Daten. Dies birgt Gefahren. Was passiert, wenn
-6-
3.2.2 Arbeitsbereich und Übertragung
zwei Entwickler an der gleichen Datei arbeiten? Folgendes einfaches Szenario stellt die
Probleme dar:
Entwickler A und B kommen morgens zur Arbeit und aktualisieren beide ihre Arbeitskopie. Person A macht dies zur gleichen Zeit wie Person B. Beide arbeiten nun an der
gleichen Datei „Beispiel.java“ in der gleichen Revision. Entwickler A macht um 12 Uhr
Mittagspause und „commitet“ seine Änderungen. Person B macht aber erst um 12:30
Pause und stellt seine Änderungen ebenfalls in das Repository ein. Was ist aber nun mit
den Änderungen von Person A? Sind sie überschrieben und damit komplett verschwunden?
Es ist zu erkennen, dass die Kontrolle des gemeinsamen Zugriffs auf Dateien ein wesentlicher Bestandteil eines Versionsverwaltungssystems darstellt. Deswegen widmet
sich die Arbeit in einem Kapitel genau diesem Problem später im Detail. Dort wird es
dann um Lösungsansätze wie Sperren und Merging gehen.
Ein weiterer Punkt, der bei der Kommunikation eine Rolle spielt, ist die Sicherheit. Ist
das Repository auf dem eigenen Rechner oder im lokalen Firmennetzwerk angelegt, ist
das Risiko nicht so hoch. Basiert die Struktur des Projektes aber auf einer weiten örtlichen Verteilung der Mitarbeiter mit Nutzung des Internets, ist dieser Aspekt nicht zu
vernachlässigen. Denn generierter Quellcode, der sowohl beim check out als auch beim
commit übertragen wird, soll sicher nicht in die falschen Hände geraten. Es ist also erforderlich die Übertragung zu sichern. Zum einen kann dies durch die Authentifizierung
der Benutzer geschehen und zum anderen durch die Sicherung der eigentlichen Übertragung. Aber nun zur Arbeitsweise der einzelnen Werkzeuge.
Wieder beginne ich bei der Darstellung der einzelnen Systeme mit CVS. Gegeben ist
das gleiche Projekt wie in Kapitel 3.2.1. Zunächst muss der Benutzer sein Arbeitsverzeichnis für sich definieren. Jetzt sei es c:\work. Dann müssen die Daten aus dem Projekt in das Arbeitsverzeichnis eingefügt werden:
C:\work> cvs –d C:\sandbox checkout Lala
Antwort von CVS:
cvs checkout: Updating Lala
U Lala/Farben.txt
U Lala/Zahlen.txt
Nun sind die Dateien im Arbeitsverzeichnis und es kann an ihnen gearbeitet werden.
Das „U“ in den beiden letzten Zeilen verdeutlicht nur, dass es sich bei den Dateien um
ein Update handelt.
CVS bietet im Bereich der Kommunikation folgende Eigenschaften. Zum einen ist es
-7-
3.2.2 Arbeitsbereich und Übertragung
ein klassisches Client-Server-Modell. Die Kommunikation der Clients mit dem Server
kann über verschiedene Methoden ablaufen. Eine Möglichkeit ist die :pserver: Methode.
Hier findet eine einfache Socket - Verbindung mit Authentifizierung der Clients statt.
Problematisch ist allerdings die unverschlüsselte Übertragung der Daten und die zu geringe Sicherung der Authentifizierung. Eine andere Methode ist das rsh – Protokoll. Ein
Vorteil dieser Methode ist, dass die Authentifizierung nicht über Passwortdaten funktioniert, sondern über eine Betriebssystemauthentifizierung. Allerdings werden weiterhin
alle Daten unverschlüsselt übertragen. Die letzte Möglichkeit ist die der „secure shells“
(ssh). Hier werden Daten nach genormten Sicherheitsstandards übertragen. Allerdings
ist CVS in diesem Falle nur das ausführende Organ von ssh, da CVS diese Sicherheitsaspekte nicht selber anbietet, sondern sich auf andere Hersteller verlässt [PVC03, S.51]
In der Praxis läuft die Kommunikation folgendermaßen ab. Der Befehl „check out“
wurde schon kurz angesprochen.
Der Befehl
C:\work> cvs –d C:\sandbox checkout Lala
führt dazu, dass CVS alle Dateien in meinem Arbeitsbereich aktualisiert und ich somit
an der letzten Revision der Dateien, also dem aktuellen Release, arbeiten kann.
Habe ich dann die Datei Farben.txt geändert, muss ich diese in das Repository schreiben. Dies wird folgendermaßen ausgeführt:
C:\work> cvs –d C:\sandbox commit Lala/Farben.txt
Während der Ausführung öffnet sich ein Editor Fenster, indem dann noch zusätzliche
Informationen in einer Log-Datei angegeben werden können. Dann kommt die Antwort
von CVS:
Checking in Lala/Farben.txt;
C:\sandbox\Lala\Farben.txt,v
<- - Farben.txt
New revision: 1.2; previous revision: 1.1
done
Die Arbeitsweise der Funktion „update“ wird im nächsten Kapitel erläutert, da sie dort
eine gewichtige Rolle spielt.
In Subversion funktioniert das check out analog mit folgender Gestalt des Befehls:
$ svn checkout file:///c:/Pfad /zum/Repository
wobei der Befehl aus dem Verzeichnis der Arbeitskopie gestartet wird.
Bezüglich der Sicherheit bietet Subversion eine gute Unterstützung. Zum einen kann ein
Protokoll benutzt werden, was sich WebDAV + DeltaV nennt und über https gesichert
-8-
3.2.2 Arbeitsbereich und Übertragung
werden kann, oder ein weiteres eigenes Protokoll, dass durch die bereits erwähnten SSH
- Verbindung geschützt wird [VCSUB04, S.103]
Die Übertragung in das Repository läuft ähnlich wie in CVS, benötigt nur weniger Angaben. Habe ich eine Datei „xy“ geändert und ich befinde mich in meinem Arbeitsverzeichnis reicht der Befehl
$ svn commit –m „Datei xy geändert“
aus. Es wird dann nur die geänderte Datei übertragen und die Revisionsnummer inkrementiert. Der Anhang „-m“ hat nur die Bedeutung, dass der folgende Text als Kommentar eingefügt wird. Ein wesentlicher Unterschied zu CVS ist die Atomarität der Transaktionen. Dies ist ein Problem von CVS, denn dort sind die „commit“ Operationen nicht
atomar. Die Daten im Repository können also inkonsistent sein. Subversion bietet im
Gegensatz dazu die Atomarität an.
Im Falle von ClearCase arbeitet der Entwickler auf einer Sicht des Repositories. Möglich sind hier einmal „snapshot views“ und zum anderen „dynamic Views“. Die erste
Sicht stellt eine Kopie des VOB auf dem eigenen Rechner dar. Die dynamische Sicht
benutzt das „multiversion file system“, welches von ClearCase zur Verfügung gestellt
wird. Es bietet einen aktuellen und transparenten Zugriff auf die Daten in der VOB,
ohne diese auf den eigenen Rechner zu kopieren. Bei der Erstellung einer Sicht kann
man wählen, ob lieber eine statische oder eine dynamische Sicht benutzen möchte. Dies
geschieht über den „View Creation Wizard“, in dem dann auch Verzeichnisse für die
Speicherung bzw. für die dynamische Benennung angegeben werden müssen [IBM03,
S.23].Technisch gesehen wird eine Konfigurationsspezifikation, die config spec ausgewertet. Auch auf die beschriebenen Funktionen „commit“ und „check out“ kann in
ClearCase über die grafische Oberfläche zugegriffen werden. Beim „check out“ muss
im ClearCase Explorer in das entsprechende Verzeichnis des VOB`s navigiert werden
und auf die Windows-Art mit der rechten Maustaste auf der gewählten Datei der Befehl
„check out“ gewählt werden. Auch hier kann wieder ein Kommentar eingefügt werden.
Weiterhin existieren zwei Möglichkeiten der Übertragung an das Repository. Das reservierte und das unreservierte „check out“. Reserviert bedeutet hier, dass nur die eine
Sicht auf das VOB das Recht hat, eine Datei im Repository zu aktualisieren, sie also im
Prinzip eine Sperre auf der Datei hält. Unreserviert meint, dass nicht garantiert ist, dass
die übertragene Datei auch wirklich in dieser Revision im Repository steht [IBM03, S.
44]. Der bisher als „commit“ beschriebene Befehl nennt sich in ClearCase „check in“
und ist wie „check out“ über die rechte Maustaste erreichbar. Auch beim „check in“
-9-
3.2.2 Arbeitsbereich und Übertragung
können wieder Kommentare vom Entwickler angegeben werden. Allerdings muss hier
beiden Befehlen wieder zwischen der statischen und der dynamischen Sicht unterschieden werden [IBM03, S.46].
3.2.3 Sperren und Merging
Wie eben beschrieben birgt der gemeinsame Zugriff auf Daten die Gefahr, dass Änderungen verloren gehen können. Noch einmal zur Erinnerung, folgende Situation soll
vermieden werden. Entwickler A und B arbeiten am Code derselben Datei derselben
Revision. Entwickler A stellt seine Änderungen in das Repository ein. Später tut dies
Entwickler B ebenso. Existieren keine Regeln des gemeinsamen Zugriffs, gehen die
Änderungen des Entwicklers A verloren, bzw. sind in der aktuellen Revision der Datei
nicht mehr existent. Zur Lösung dieses Problems gibt es in Versionsverwaltungssystemen grundsätzlich zwei Lösungen. Zum einen das Sperren von Dateien und zum anderen das Merging, also Zusammenfügen von Dateien.
Das Sperrverfahren läuft folgendermaßen ab. Bevor ein Entwickler an einer Datei arbeiten kann, muss er die Datei sperren. Ist dies geschehen, können andere Mitarbeiter diese
Datei zwar noch lesen, aber nicht mehr bearbeiten [VCSUB04, Kapitel 2.2.2]. Ein Beispiel ist in Abbildung 1 dargestellt:
Entwickler B
Repository
Entwickler A
Beispiel.java
sperren
checkout
Entwickler A sperrt Datei Beispiel. Java und kopiert sie in
seinen Arbeitsbereich
Versuch schlägt fehl, Datei
bereits gesperrt
ändern
Entwickler A hat Datei verändert, schickt sie zum Repository
und entsperrt sie
Entwickler B möchte Datei Beispiel.java sperren
commit
entsperren
Beispiel.java
checkout
sperren
Jetzt kann Entwickler B Datei
Beispiel.java sperren und lesen
Abbildung 1: Sperrverfahren
-10-
3.2.3 Sperren und Merging
Es ist also zu erkennen, dass das Sperrverfahren das oben beschriebene Problem löst. Es
gehen also keine Änderungen verloren. Gemeinsamer schreibender Zugriff auf eine
Datei findet nicht statt.
Allerdings birgt diese Lösung auch einige Nachteile. Zum einen könnte Entwickler A
vergessen, die Sperre auf der Datei Beispiel.java aufzuheben. Dies hätte zur Folge, dass
Entwickler B unnötig lange warten müsste, bis er seine Änderungen durchführen kann.
Eventuell muss sogar erst der Administrator die Sperre der Datei aufheben. Es besteht
also die Möglichkeit, dass die Produktivität aufgrund dieses Verfahrens stark zurückgeht.
Weiterhin impliziert das Sperren die Verhinderung jeglichen gemeinsamen schreibenden Zugriffs auf eine Datei. Dies ist aber nicht unbedingt notwendig. Arbeiten zwei
Entwickler zum Beispiel an komplett unterschiedlichen Teilen des Codes einer Datei,
besteht kein Grund, warum sie dies nicht gleichzeitig tun sollten. Die Änderungen
könnten nach Bearbeitung zusammengefügt werden.
Eine andere Möglichkeit der Organisation des gemeinsamen Zugriffs ist das so genannte Merging, was auch als optimistisches Sperren bezeichnet wird. Es ist nicht so strikt
wie das Sperrverfahren und erlaubt mehreren Entwicklern Änderungen einer Datei zur
gleichen Zeit. Der Ablauf ist folgendermaßen organisiert. Entwickler A und B wollen
die gleiche Datei Beispiel.java bearbeiten. Sie holen sich per „check out“ die gleiche
Revision in ihre Arbeitskopie und führen ihre Änderungen durch. Entwickler A schreibt
nun als erster seine Änderungen per commit in das Repository zurück. Kurze Zeit später
tut dies auch Entwickler B, der nun eine Nachricht vom Versionsverwaltungssystem
erhält, dass nicht die aktuellste Version der Datei in seiner Arbeitskopie enthalten ist.
Durch ein Update erhält Entwickler B die aktuelle Version. Nun besteht zum einen die
Möglichkeit, dass die Änderungen von Entwickler A nicht mit denen von Entwickler B
kollidieren, die Dateien können zusammengefügt werden und ins Repository geschrieben werden [VCSUB, Kapitel 2.2.2]. Es sind nun alle gemachten Änderungen in der
aktuellen Version enthalten. Dieser Ablauf wird in Abbildung 2 dargestellt:
-11-
3.2.3 Sperren und Merging
Entwickler A
lesen
public class Beispiel {
public string getName ( ) {
return „Lars“;
}
public int getSize ( ) {
return „180“;
}
}
Repository
Entwickler B
public class Beispiel {
public string getName ( ) {
return „Lars“;
}
public int getSize ( ) {
return „180“;
}
}
lesen
public class Beispiel {
public string getName ( ) {
return „Lars“;
}
public int getSize ( ) {
return „180“;
}
}
ändern
…
public string getName ( ) {
return „Fischer“;
}
…
ändern
commit
public class Beispiel {
public string getName ( ) {
return „Fischer“;
}
public int getSize ( ) {
return „180“;
}
}
…
public int getSize ( ) {
return „190“;
}
…
commit
Konflikt!
Entwickler hat nicht aktuellste
Version von Datei
Update und
zusammenfügen
commit
public class Beispiel {
public string getName ( ) {
return „Fischer“;
}
public int getSize ( ) {
return „190“;
}
}
public class Beispiel {
public string getName ( ) {
return „Fischer“;
}
public int getSize ( ) {
return „190“;
}
}
Abbildung 2: optimistisches Sperren
-12-
3.2.3 Sperren und Merging
Wenn also zwei Entwickler unterschiedliche Teile einer Datei ändern, sind alle Änderungen in der aktuellen Revision im Repository enthalten. In der Situation, in der Entwickler B das commit ausführen will, erkennt das Versionsverwaltungssystem, dass die
Arbeitskopie von „B“ nicht aktuell ist. Es führt also das Update aus, erkennt, dass die
Änderungen nicht untereinander kollidieren und führt das commit aus.
Was passiert aber wenn beide gleiche Codezeilen verändern wollen. Im obigen Beispiel
wollen sowohl Entwickler A als auch B den Namen (Zeile 3) ändern. Bis zum dem
Zeitpunkt wo „B“ das commit ausführen will ist der Ablauf der gleiche. Das System
erkennt in diesem Augenblick (commit von „B“) aber wieder einen Konflikt. Nun ist
das System aber in der Lage zu erkennen, dass die gleiche Zeile Code in der Bearbeitungszeit der Datei bereits von „A“ geändert wurde. Um diese Änderungen nicht zu
verwerfen, zeigt das System nun Entwickler „B“ beide Möglichkeiten der Datei an, also
seine und die des Entwicklers A. Nun kann Entwickler B, eventuell nach Kontaktaufnahme mit Entwickler A, entscheiden, welche der beiden Möglichkeiten er wählt.
Gegenüber dem Sperrverfahren hat das Merging den Vorteil, dass viele Entwickler
wirklich parallel arbeiten können. Sie müssen nicht auf das Aufheben von Sperren warten. Somit entstehen keine langen Leerlaufzeiten, also eine höhere Produktivität.
Die Vermutung, dass durch das gleichzeitige Bearbeiten der gleichen Dateien viele
Probleme entstehen können ist eher unbegründet. In der Praxis ist es selten der Fall,
dass mehrere Entwickler die gleichen Codezeilen ändern [VCSUB04, Kap. 2.2.2].
Wenn dies dann tatsächlich passiert, ist der Erfolg des Systems von der Kommunikation
der Entwickler untereinander abhängig. Die Entwickler müssen untereinander abstimmen, welche Lösung für ihr Projekt die Beste ist.
Ein Kritikpunkt an beiden Verfahren ist die Fokussierung auf nur eine Datei. Bearbeiten
zwei Entwickler zwei verschiedene Dateien, bei denen aber Interdependenzen bestehen
und sprechen sich nicht ab, reagieren beide Verfahren nicht, aber die geänderten Dateien können zu einer nicht arbeitenden Version führen. Es müssen also erst Funktionstests
durchgeführt werden,
Interessant ist nun, wie CVS, Subversion und ClearCase vorgehen. CVS benutzt das
optimistische Sperrverfahren [OSD03, S.18]. Dies lässt sich gut an dem bereits behandelten Beispiel aus Abbildung 2 erklären und erkennen. Es existieren zwei Arbeitsbereiche C:\work und C:\work2, die nun Entwickler A und Entwickler B entsprechen. Wie
in Abbildung 2, ändert Entwickler A die dritte Zeile und Entwickler B die sechste Zeile
der Datei. Nun will Entwickler A seine Änderungen in das Repository schreiben. Er tut
-13-
3.2.3 Sperren und Merging
dieses mit dem Befehl commit:
C:\work> cvs –d C:\sandbox commit Lala/Beispiel.java
Antwort von CVS:
Checking in Lala/Beispiel.java;
C:\sandbox/Lala/Beispiel.java,v
<--
Beispiel.java
new revision: 1.2; previous revision: 1.1
done
Nun ist die Revision von Entwickler A im Repository. Entwickler B legt nach und führt
ebenfalls commit aus:
C:\work2> cvs –d C:\sandbox commit Lala/Beispiel.java
Antwort von CVS:
cvs commit: Up-to-date check failed for
`Lala/Beispiel.java'
cvs [commit aborted]: correct above errors first!
Die Revision der Datei ist also nicht mehr aktuell und CVS sagt dem Entwickler, er soll
ein update durchführen:
C:\work2> cvs –d C:\sandbox update Lala/Beispiel.java
Antwort von CVS:
RCS file: C:\sandbox/Lala/Beispiel.java,v
retrieving revision 1.1
retrieving revision 1.2
Merging differences between 1.1 and 1.2 into
Beispiel.java
M Lala/Beispiel.java
cvs update: in directory Lala/Beispiel.java:
Es ist zu erkennen, dass CVS die beiden Versionen der Datei zusammengefügt hat in
eine neue Version der Datei. Nun sind sowohl die Änderungen von Entwickler A, als
auch von B enthalten, obwohl beide gleichzeitig an der Datei gearbeitet haben.
Aber was macht das System, wenn beide Entwickler die gleiche Zeile verändern. Entwickler A ändert nun den Namen in „Fischer“ und Entwickler B selbigen in „Schwimmer“. Zunächst ist der Ablauf identisch. Entwickler A überträgt seine Revision in das
Repository. Nun will dies auch Entwickler B mit dem bekannten Befehl commit tun. Er
erhält auch zunächst die gleiche Nachricht, also die Aufforderung nach einem update,
was er dann ausführt:
C:\work2> cvs –d C:\sandbox update Lala/Beispiel.java
-14-
3.2.3 Sperren und Merging
Antwort von CVS:
RCS file: C:\sandbox/Lala/Beispiel.java,v
retrieving revision 1.2
retrieving revision 1.3
Merging differences between 1.2 and 1.3 into
Beispiel.java
rcsmerge: warning: conflicts during merge
cvs update: conflicts found in Lala/Beispiel.java
C Lala/Beispiel.java
cvs update: in directory Lala/Beispiel.java:
In diesem Fall erkennt CVS also, dass es die Änderungen nicht verschmelzen kann und
meldet dies dem Nutzer. Es findet trotzdem ein Update statt. Entwickler B hat nun in
seiner Datei Beispiel.java beide Versionen:
public class Beispiel {
public string getName ( ) {
<<<<<<< Beispiel.java
return „Schwimmer“;
=======
return „Fischerman“;
>>>>>>> 1.3
}
public int getSize ( ) {
return „200“;
}
}
Die kursiv geschriebenen Zeilen stellen nun das Resultat von CVS dar. Entwickler B
sieht beide Versionen und kann sich nun mit Entwickler A in Verbindung setzten und
beraten, welche die Richtige ist. Wenn er sich entschieden hat, muss er nur noch den
Code dementsprechend verändern und kann das commit durchführen ohne einen Fehler
zu erhalten.
In Subversion ist die Konfliktauflösung wie in CVS geregelt [SUVCS05, Kap. 2.1].
Einziger Unterschied ist die etwas andere Syntax der Befehle, die ja schon in den vorherigen Kapiteln zu sehen war. Dieser Unterschied ist allerdings zu vernachlässigen, da
beide Systeme prinzipiell auf die gleiche Weise arbeiten. Ein detailliertes Bespiel ist
-15-
3.2.3 Sperren und Merging
hier [SUVCS05, Kap. 4.10] zu finden.
In diesem Bereich stellt ClearCase einen anderen Vertreter dar. Die größere Komplexität des Systems wurde schon angesprochen und zeigt sich hier. Als Standart ist das pessimistische Sperrverfahren, also das in Abbildung 1 gezeigte Verfahren zu nutzen. Das
System kann aber angepasst werden, so dass das optimistische Sperren Anwendung
finden kann. Die Wahl liegt beim Benutzer.
3.2.4 Versionen, Revisionen
Der Begriff Version ist in der Arbeit schon häufiger gefallen. Nun geht es darum ihn
etwas genauer zu beleuchten. Interessant ist die Frage, wie ein Versionsverwaltungssystem Versionsnummern, bzw. Revisionsnummern vergibt und was sich aus ihnen erkennen lässt.
Um dies zu klären, ist es wichtig daran zu denken, dass im Repository nicht nur die aktuellen Daten, sonder alle jemals erstellten Daten gespeichert sind. Also jede Revision
jeder Datei. Weiterhin ist für jede Datei das Änderungsdatum und eventuell ein Kommentar des Entwicklers enthalten.
Hat die Datei Beispiel.java also zu Beginn die Revisionsnummer 1.1 erhält sie nach
einer Änderung die Nummer 1.2. Das klingt einfach, ist es aber leider nicht. In den verschiedenen Versionsverwaltungssystemen gibt es keine einheitliche Handhabung, wie
Änderungen nummeriert werden. Deshalb stelle ich nun die Konzepte für die drei bekannten Systeme vor.
CVS benutzt Revisionsnummern einzeln für jede Datei [PVC03, S.14-15]. Dies kann
am besten an einem Beispiel illustriert werden. Es existieren zwei Dateien mit den Versionsnummern:
Beispiel1.java
1.4
Beispiel2.java
1.6
Nun wird nur Datei Beispiel1.java geändert und ins Repository übertragen. Die Revisionsnummer wird erhöht, allerdings nur die von Beispiel1.java:
Beispiel1.java
1.5
Beispiel2.java
1.6
Dies hat zur Folge, dass die Revisionsnummern keinen Aufschluss darüber geben, ob
und in welchem Release des Softwareprojektes, also welcher Version, sie genutzt werden. Sie sind rein auf die Datei - Änderungen bezogen. Release 5 bedeutet also nicht,
-16-
3.2.4 Versionen, Revisionen
dass die Dateien mit den Nummern *.5 in diesem Release benutzt werden, es könnten
auch Dateien *.9 oder ähnliches sein. Es ist also an der Nummer eines Releases nicht zu
erkennen, welche Dateirevisionen in ihr verwendet werden. Zu diesem Zweck existieren
Tags, die im nächsten Kapitel angesprochen werden.
Trotzdem lässt diese Art der Nummerierung einige Rückschlüsse zu. Da das Änderungsdatum gespeichert ist, lassen sich zum Beispiel Änderungen in einem bestimmten
Zeitraum, z.B. einem Monat, erkennen. Natürlich können auch ältere Revisionen einer
Datei wiederhergestellt oder Änderungen zwischen zwei Revisionen einer Datei angezeigt werden.
Bei Subversion sieht das Prinzip etwas anders aus. Hier werden Revisionsnummern
global für das Repository vergeben, und nicht fortlaufend für eine Datei [SUVCS05,
Kap. 1.3.2]. Dies kann wieder an einem Beispiel gezeigt werden. Es existieren wieder
die beiden Dateien mit ihren Revisionsnummern:
Beispiel1.java
1.2
Beispiel2.java
1.2
In Subversion impliziert dies nun, dass genau diese Dateirevisionen in Release 2 benutzt
werden. Wird nun nur Datei Beispiel1.java geändert, werden alle Änderungsnummern
aller Dateien im Projekt geändert:
Beispiel1.java
1.3
Beispiel2.java
1.3
Dies geschieht, obwohl nur Beispiel1.java verändert wurde.
Eine Folge dieser globalen Änderungsnummern ist die schnell wachsende Zahl der
Nummern, da jedes commit eine Inkrementierung der Nummern zur Folge hat. Der
Vorteil besteht aber in der besseren Struktur. Es müssen nicht zusätzliche Befehle wie
in CVS ausgeführt werden, um ein Release zu kennzeichnen.
Ein Nachteil ist die Tatsache, dass die Anzahl an Änderungen einer Datei nicht so einfach nachzuvollziehen ist wie in Datei - basierten Systemen wie CVS, da die Änderungsnummer nicht zwingend eine Modifikation bedeutet.
Auch ClearCase vergibt Änderungsnummern. Welchem Prinzip die Software folgt,
wurde aus der Literatur und ohne praktischen Test leider nicht ersichtlich.
3.2.5 Tags
Wie in Kapitel 3.2.5 beschrieben, sagen Revisionsnummern nicht zwingend etwas über
-17-
3.2.5 Tags
die Verwendung in einer Softwareversion aus. In CVS ist dies der Fall. Versionsverwaltungssysteme bieten eine weitere Funktionalität, die sich tagging nennt und dieses Problem behebt.
Mittels dieser Funktion können Elemente des Repositories markiert und so einem bestimmten Release der Software zugeordnet werden. Möchte ich also für ein Release
kennzeichnen, welche Dateirevisionen in diesem benutzt werden, führe ich den Befehl
„tag“ aus, und ich erhalte eine eindeutige Kennzeichnung. Vor allem für Systeme wie
CVS, die dateibezogen Revisionsnummern vergeben ist dies von Vorteil. Ich kann nun
eine Markierung mit dem Namen „Release 2“ erstellen und dieser Dateien mit verschiedenen Revisionsnummern zuordnen. Benutzt wird diese Funktion vor allem an Meilensteinen in einem Projekt. Zudem ist ein großer Vorteil, dass so ältere lauffähige Versionen der Software wiederhergestellt werden können, wenn eine neuere Version zu viele
Fehler aufweist [PVC03, Kap. 2.6].
In CVS ist dies einfach zu realisieren. Entwickler A möchte nun die Dateien in seinem
Arbeitsverzeichnis mittels eines Tags markieren. Es sollen also die Revisionen der
Dateien markiert werden, die zu diesem Zeitpunkt das Release darstellen. Dies
geschieht mit dem einfachen Befehl:
C:\work\Lala> cvs –d C:\sandbox tag Rel_1
Unter der Annahme, dass wieder die schon betrachteten Dateien Farben.txt und Zahlen.txt betrachtet werden, antwortet CVS:
cvs tag: Tagging .
T Farben.txt
T Zahlen.txt
Die Dateien sind nun markiert mit dem Namen Rel_1. Es ist nun möglich, genau diese
Revisionen der Dateien zu einem späteren Zeitpunkt wiederherzustellen, bzw. genauer
gesagt, das entsprechende Release ist reproduzierbar.
Dies ist aber nur ein kleiner Teil der Möglichkeiten, die CVS bietet. Neben dem dem
Befehl tag, existiert auch noch der Befehl rtag (releasetag), der aber eine Synchronisation mit dem Repository voraussetzt. Genauere Informationen würden hier den Rahmen
der Arbeit sprengen, können aber nachgelesen werden [PVC03, Kap. 7.1].
In Subversion sieht dies zwar ähnlich aus, hat aber einen anderen Hintergrund. Wie in
Kapitel 3.2.5 schon beschrieben, sind ja schon die Revisionsnummern kennzeichnend
für eine Version der Software. Ein Tag macht hier nichts anderes, nur eine eigene Namensgebung ist möglich. Technisch gesehen, bildet Subversion ein neues Verzeichnis
-18-
3.2.5 Tags
im Repository mit dem Namen des Tags [VCSUB04, S. 56]. Dies alles geschieht mit
dem Befehl „copy“:
C:\work> svn copy file:///c:/Pfad/zum/Repository
file:///c:/Pfad/zum/Repository/tags/release_1_1
Gespeichert wird das Tag in einem Ordner „tags“ im Repository.
In ClearCase nennen sich tags nun Labels, stellen aber die gleiche Funktionalität, also
das Markieren von Revisionen von Dateien dar [ACCD04, Kap. 12.2].
3.2.6 Branching
Diese Funktionalität erlaubt den Benutzern auf mehreren Entwicklungszweigen zu arbeiten [PVC03, Kap. 2.7]. Damit ist folgendes gemeint. Im normalen Fall arbeiten alle
Entwickler in einem Projekt an dem gleichen Code, der „mainline“ des Projektes. Zu
einem bestimmten Zeitpunkt soll nun ein Release an die Öffentlichkeit gehen. Das Entwicklerteam teilt sich hierfür auf. Der eine Teil ist nun für die Erstellung eines lauffähigen Releases zuständig, der andere Teil soll den Code, wie vorher, weiter entwickeln.
Extrem wichtig für das Release-Team ist nun natürlich, dass der Code stabil bleibt, also
keine großen Änderungen mehr auftreten, da sonst eventuell keine lauffähige Version
zu Stande kommen kann. Aber wie funktioniert das? Der Rest des Teams kann nicht
einfach aufhören zu arbeiten, nur weil der Code in der „mainline“ nicht mehr verändert
werden soll. Die Lösung ist die Abkopplung des Codes in einen weiteren Entwicklungszweig. Zu einem bestimmten Zeitpunkt wird der komplette Code in einen neuen Entwicklungszweig kopiert, an dem nun nur noch das Release-Team arbeitet. Der Rest der
Entwickler führt seine Arbeit weiter am Code in der „mainline“ durch, so dass parallel
gearbeitet werden kann.
Auch Fehler die in dem veröffentlichten Release gefunden werden, korrigiert die Release-Gruppe nur in ihrem Zweig, nicht in der „mainline“.
Eine Frage ist natürlich, was passiert, wenn erkannt wird, dass Fehler in dem Release
auch in der „mainline“ vorhanden sind? Zu diesem Zweck bietet das Versionsverwaltungssystem die Funktionalität des Zusammenfügens. Eine Datei in dem Entwicklungszweig Release kann mit einer aus der „mainline“ verglichen werden und die Unterschiede in der „mainline“ korrigiert werden.
Branching ermöglicht also eine unabhängige, parallele Bearbeitung des Codes für verschiedene Zwecke.
-19-
3.2.6 Branching
In CVS wird Branching mittels des tag-Befehls realisiert. Wenn Entwickler B einen
neuen Zweig neben der mainline eröffnen möchte, tut er dies folgendermaßen:
C:\work2\Lala> cvs –d C:\sandbox tag –b Branch_1
Antwort von CVS:
cvs tag: Tagging .
T Farben.txt
T Zahlen.txt
Die Antwort ist also identisch mit der aus Kapitel 3, das eigentliche Ergebnis aber ein
anderes. Es existiert nun ein weiterer Entwicklungszweig Branch_1 in dem Projekt, auf
dem separat Dateien bearbeitet werden können. Zusammengefügt werden die Entwicklungszweige dann mit dem Befehl „update –j“. Dies führt hier zum Beispiel Entwickler
A aus, unter der Annahme, dass Entwickler B die Datei Zahlen.txt geändert hatte:
C:\work\Lala> cvs –d C:\sandbox update –j Branche_1
Antwort von CVS:
cvs update: Updating .
RCS file: C:\sandbox/Lala/Zahlen.txt,v
retrieving revision 1.2
retrieving revision 1.2.2.1
Merging differences between 1.2 and 1.2.2.1 into
Zahlen.txt
cvs update: Updating Lala
Nun sind die Entwicklungszweige wieder zusammengefügt und aktuell.
In Subversion ist die Syntax zur Erstellung eines neuen Entwicklungszweiges analog
zur Erstellung eines Tags. Lediglich das Ziel befindet sich nun nicht im Ordner „tags“,
sondern im Ordner „branches“ [VCSUB04, S. 42].
Natürlich bietet auch ClearCase das Prinzip mehrerer Entwicklungszweige an. Die Erstellung kann wie schon bei den vorherigen Funktionen über den ClearCase Explorer
geschehen. Weiterhin ist es in ClearCase natürlich auch möglich, verschiedene Entwicklungszweige wieder zu einem Zweig zusammen zu fügen.
-20-
4 Zusammenfassung und Ausblick
4 Zusammenfassung und Ausblick
In Laufe dieser Arbeit bin ich auf die Grundfunktionen von Versionsverwaltungssystemen eingegangen. Zum einen wurde beschrieben, wie Anforderungen an ein solches
System aussehen und wie diese theoretisch umgesetzt werden können. Eine wichtige
Rolle spielte hier die Änderungsverwaltung und das verteilte Arbeiten.
Weiterhin wurden die grundsätzlichen Arbeitsweisen der drei vorgestellten Werkzeuge
beschrieben, um einen kleinen Einblick in das praktische Arbeiten zu geben.
Es muss aber gesagt werden, dass dies zum einen nur einen kleinen Einblick in die Versionsverwaltung sein kann und zum anderen die Werkzeuge deutlich mehr Funktionalität aufweisen, als in dieser Arbeit dargestellt werden konnte.
Diese Systeme sind in der Lage, Unterschiede zwischen Revisionen von Dateien, zwischen Versionen der Software oder mehreren Entwicklungszweigen darzustellen und zu
analysieren. Auch wurden in der Arbeit nicht die Zugriffsmechanismen auf das Repository detailliert beschrieben.
Als letztes muss auch gesagt werden, dass neben den beschriebenen Werkzeugen viele
andere auf dem Markt erhältlich sind, so dass es sich bei CVS, Subversion und ClearCase zwar um bekannte Vertreter handelt, diese aber keineswegs ausschließlich benutzt
werden.
Zusammenfassend kann man sagen, dass diese Seminararbeit nur eine Einführung in die
Versionsverwaltung und deren Werkzeuge darstellen kann und die gesamte Komplexität
nur im Ansatz darstellt.
-21-
Literaturverzeichnis
Literaturverzeichnis:
[IBM03]
IBM Rational Software, Working in ClearCase for Windows, 2003
[CC04]
Ueli Wali, Jenni Brown, Matti Teinonen, Trulsson: Software
Configuration Management – A Clear Case for IBM Rational ClearCase
and ClearQuest UCM, ibm.com/redbooks, 2004
[SCM05]
David E. Bellagio, Tom J. Milligan: Software Configuration Management Strategies and IBM Rational ClearCase – Second Edition – Practical Introduction
[EsCVS03]
Jennifer Vespermann: Essential CVS, O`Reilly, 2003
[PVC03]
David Thomas, Andrew Hunt: Pragmatic Version Control with CVS, The
Pragmatic Programmers, 2003
[OSD03]
Moshe Bar, Karl Fogel: Open Source Development with CVS, Paragraph
Press, 2003
[VCSUB04] Ben Collins-Sussman, Brian W. Fitzpatrick, C. Michael Pilato: Version
Control with Subversion, O`Reilly, 2004
[SUVCS05]
William Nagel: Subversion Version Control: Using the Subversion
Version Control System in Development, Prentice Hall, 2005
[WIKIS]
wikipedia: Subversion (Software),
http://de.wikipedia.org/wiki/subversion(software)
[ACCD04]
Christian P. Buckley, Darren W. Pulsipher: The Art of ClearCase
Deployment – The Secret to successful Implementation, Addison Wesley,
2004