Ziel der Versionsverwaltung in Softwareprojekten ist, den Ablauf der
Entwicklung zu protokollieren und zu erleichtern. Dazu zählt das
Nachverfolgen von Änderungen (Wer hat wann was gemacht?), sowie das
Rückgängigmachen bei eventuell auftretenden Fehlern, außerdem ergibt
sich dadurch eine Möglichkeit des Datenbackups. Desweiteren soll das
Parallelarbeiten im Team unabhängig voneinander stattfinden , d.h.
jeder Entwickler hat seinen eigenen Entwicklungszweig, und die
Ergebnisse dann zu einem kompletten System zusammengefasst werden.
Begriffe
Repository
Das Repository ist das (zentrale) Archiv, welches alle Revisionen sowie
Dateien neben dazugehöriger Logdateien in Form einer Baumstruktur
enthält.
Working Directory
Die Working Directory bezeichnet das lokale Arbeitsverzeichnis eines Benutzers.
Revision
Eine Revision bezeichnet einen bestimmten Entwicklungsstand. Sie wird erzeugt, indem der Anwender Änderungen aus seinem Working Directory in
ein Repository überträgt. Nebenher werden außerdem das Datum, der Autor und ein beschreibender Kommentar gespeichert, sowie eine eindeutige
Revisionsnummer erzeugt.
Branch
Als Branch wird ein einzelner Entwicklungszweig gekennzeichnet. Er besteht aus einer Reihe von Revisionen.
Tag
Dies bezeichnet ein Etikett, das der Autor einer Revision geben kann. Dadurch ist es möglich spezielle Revisionen zu kennzeichnen (z.B.
Versionsnummern).
Konflikt
Ein Konflikt tritt immer dann auf, wenn verschiedene Nutzer an der selben Stelle in einer Datei Änderungen vornehmen und dann übertragen
wollen.
Snapshot
Als Snapshot wird ein aktuelles Abbild des Working Directory bezeichnet.
Change Set
Das Change Set beinhaltet alle Änderungen zwischen zwei Revisionen, bzw. zwischen verschiedenen Dateiversionen.
Commit
Dies bezeichnet den Vorgang um eine neue Revision zu erzeugen.
Update
Hierbei handelt es sich um den umgekehrten Vorgang des Commit. Hierbei werden Daten aus dem Repository in das Working Directory
übertragen.
Pull
Kommando zum Übertragen von Dateien von einem fremden Repository ins Eigene.
Push
Dies ist die Umkehrung des Pull-Kommandos. Dateien werden aus dem eigenen Repository in ein Fremdes übertragen.
Clone
Hiermit wird eine 1:1 Kopie eines Repositorys erstellt.
Merge
Merge ermöglicht das Zusammenführen von parallelen Entwicklungszweigen.
Als Zentrale Versionsverwaltung wird das Arbeiten mit einem Repository bezeichnet auf das alle Benutzer zugreifen.
Jeder Benutzer besitzt außerdem ein lokales Working Directory mit dem er arbeitet.
Abbildung 1: Zentrale Versionsverwaltung
Revision Control System (RCS)
Das RCS wurde Anfang der 80er Jahre von Walter F. Tichy entwickelt und ist heute Teil des GNU Projekts. Es arbeitet lediglich auf
Dateiebene, Verzeichnisstrukturen kÄnnen nicht verwaltet werden.
Concurrent Versions Control (CVS)
Das CVS wurde Mitte/Ende der 80er Jahre von Dick Grune entwickelt. Es unterstützt das Konzept des Branching, d.h. es kann mehrere
Entwicklungszweige geben. Allerdings ermöglicht es nicht das Umbennen und Verschieben von Dateien, auch eine Unterstützung für Verzeichnisse
fehlt.
Subversion (SVN)
Subversion ist der Nachfolger von CVS (erste Veröffentlichung 2000) und bietet ein Vielzahl von Verbesserungen. So gibt es jetzt eine
vollständige Unterstützung von Verzeichnissen und symbolischen Links, sowie von Umbennenungen und Verschiebungen auf Datei-
und Verzeichnisebene und dadurch eine bessere Konsistenz in den Logdateien. Die Revisionsnummer bezieht sich jetzt immer auf die
gesamte Revision und nicht mehr auf die einzelne Datei. Der Datenaustausch kann mit bekannten Netzwerkprotokollen
(z.B. HTTP) erfolgen, außerdem sind Commits jetzt immer atomar.
Nachteile Zentraler Versionsverwaltung
Der wesentliche Nachteil der Zentralen Versionsverwaltung ergibt sich aus dem Vorhandensein nur eines Repositorys. Da dieses in der Regel auf
einem zentralen Server liegt, ist für jedes Commit eine Onlineverbindung nötig, welche außerdem langsamer als ein lokaler Zugriff ist.
Weil jede Revision im Repository liegt, ist sie somit für alle, die Zugriff haben, sichtbar, auch wenn es sich nur um experimentelle Revisionen
handelt. Desweiteren besteht beim Auftreten von Konflikten die Gefahr, dass Informationen verschwinden, da sie bei der Auflösung des Konflikts aus der
Arbeitskopie gelöscht werden ohne vorher ins Repository übertragen zu werden.
Im Unterschied zur Zentralen Versionsverwaltung besitzt jeder Nutzer jetzt ein eigenes Repository, in welches er seine Änderungen einpflegen
kann. Dieser Vorgang ist schneller, da kein Netzwerkzugriff erfolgen muss, außerdem ist jeder commit konfliktfrei, somit kann kein Datenverlust beim
mergen auftreten. Kommt es hierbei zu Fehlern, kann eine vorige Version wiederhergestellt werden. Auch sind alle Revisionen erstmal nur im
lokalen Repository des Benutzers vorhanden und damit nicht sofort für andere sichtbar. Der Austausch mit anderen Nutzern erfolgt dann mittels
pull/push auf die jeweiligen Repositorys und kann optional auch über ein gemeinsames Repository laufen.
Abbildung 2: Verteilte Versionsverwaltung
Nachteile Verteilter Versionsverwaltung
Aufgrund der lokalen Repositorys erhöht sich der Speicherplatzbedarf. Die bei der Zentralen Revisionsverwaltung verwendeten einfachen
Revisionsnummern sind jetzt nicht mehr verwendbar und müssen durch global eindeutige Hashwerte ersetzt werden, was den direkten Zugriff auf
einzelne Revisionen erschwert. Da jeder Nutzer mit seinem lokalen Repository arbeitet, welches jeweils einen einzelnen Entwicklungszweig
repräsentiert, entsteht eine weit verzweigte Revisionsstruktur.
