25    Versionskontrolle

»Zurück in die Zukunft«

Versionskontrollsysteme oder auch Versionsverwaltungssysteme, im Englischen Version Control Systems (VCS), bieten die Möglichkeit, »in die Vergangenheit zu reisen« und alte Stände von Dateien wiederherzustellen sowie verschiedene Versionen von Dateien miteinander zu vergleichen. Versionskontrollsysteme werden überwiegend in der Softwareentwicklung zur Verwaltung von Quelltexten eingesetzt, leisten aber auch in der Systemadministration zur Verwaltung von Konfigurationsdateien gute Dienste.

[ ! ]  In diesem Kapitel werden Versionskontrollsysteme nur als Mittel zur Verwaltung von Konfigurationsdateien behandelt. Insbesondere wird davon ausgegangen, dass nur wenige Personen an den Dateien arbeiten. Das ganze Aufgabenfeld rund um Konflikte beim Zusammenführen (Mergen) von unterschiedlichen Versionsständen wird dabei bewusst ausgespart.

Die Systeme erfüllen dabei folgende Vorgaben:

Um diese Vorgaben zu erfüllen, haben sich in den letzten Jahren verschiedene Sichtweisen gebildet, und innerhalb der verschiedenen Sichtweisen existieren unterschiedliche Implementationen der Sichtweisen.

Im Großen und Ganzen lassen sich drei verschiedene Philosophien – lokal, zentral und dezentral – unterscheiden, die in Abschnitt 25.1, »Philosophien«, näher beschrieben werden.

Es gibt eine ganze Reihe an Versionskontrollsystemen, die als Open-Source-Software veröffentlicht wurden, und es existieren ebenfalls einige Vertreter aus dem Lager der Closed-Source-Software. In Tabelle 25.1 finden Sie einige Beispiele für die verschiedenen Versionskontrollsysteme, die der Wikipedia[ 40 ] entnommen wurden.

Open-Source-Systeme Proprietäre Systeme
Zentrale Systeme SCCS RCS CVS Subversion (SVN) Alienbrain Perforce Team Foundation Server Visual SourceSafe ClearCase IBM Ration Synergy PTC Integrity SAP Design in Time Repository (DTR) versiondog Sourcegear Vault
Verteilte Systeme Bazaar Bitkeeper Darcs Fossil Git GNU arch Mercurial Monotone Rational Team Concert

Tabelle 25.1    Beispiele für Versionskontrollsysteme aus der Wikipedia

25.1    Philosophien

Es gibt viele verschiedene Ansätze für die Versionskontrolle, aber im Großen und Ganzen lassen sich drei verschiedene Philosophien unterscheiden, die wir im Folgenden betrachten.

25.1.1    Lokal

Alle Versionen von Dateien werden lokal gespeichert und nicht an einen Server übertragen. Als einfachstes Beispiel mag Listing 25.1 dienen:

$ cp config config.alt
$ edit config

Listing 25.1    Einfachste Art der lokalen Versionskontrolle

Die originale Datei config wird damit in config.alt kopiert, und die ursprüngliche Datei wird verändert. Nun existieren zwei Versionen der Datei.

Es gibt Systeme und sogar Dateisysteme, die ein solches Vorgehen unterstützen und die Dateien rotierend benennen. Aus config wird config.1, bei der nächsten Änderung wird aus config.1 die Datei config.2, und aus config wird erneut config.1, so wie es Listing 25.2 zeigt:

$ cp config.1 config.2
$ cp config config.1
$ edit config

Listing 25.2    Lokale Versionskontrolle mit verschiedenen Versionen

Das lässt sich beliebig weiterdenken oder durch einen Schwellenwert – beispielsweise zwei Versionen wie in Listing 25.3 – abbrechen:

$ rm config.2
$ cp config.1 config.2
$ cp config config.1
$ edit config

Listing 25.3    Lokale Versionkontrolle, rotierend

Wenn die config ein weiteres Mal verändert wird, dann wird die älteste Version gelöscht. Allgemein üblich ist es, statt der Nummern Daten bzw. Zeitstempel einzusetzen. Damit ist auf einen Blick ersichtlich, bis zu welchem Zeitpunkt eine Konfigurationsdatei gültig war, wie Listing 25.4 zeigt:

$ cp config config.20180830
$ edit config

Listing 25.4    Lokale Versionskontrolle mit Zeitstempel

25.1.2    Zentral

Einen Schritt weiter gehen zentrale Versionskontrollsysteme. Dort wird mit den Begriffen Arbeitskopie und Repository unterschieden, in welchem Teil der Arbeitskette man sich befindet. Dateien werden in der Arbeitskopie verändert und nach Abschluss der Arbeiten – zusammen mit einer Nachricht – an eine zentrale Stelle, einen zentralen Server, geschickt. Der Server, der das Repository verwaltet, besitzt alle Versionsstände der verwalteten Dateien. Lokal in der Arbeitskopie liegt immer nur eine einzige Version der Datei vor. Will man sich Unterschiede zwischen verschiedenen Versionen anzeigen lassen, so wird für jede Version der Server beauftragt, die angeforderte Version zu schicken.

Der große Vorteil eines solchen Verfahrens besteht darin, dass lokal eine sehr aufgeräumte Arbeitskopie vorliegt, ohne dass man Dateien in vielen verschiedenen Versionen vorliegen hat, und dass zentral auf dem Server ein Backup aller alten (und auch der aktuellen) Konfigurationen vorliegt. In einer Pseudosprache sieht der Arbeitsablauf soe wie in Listing 25.5 beschrieben aus:

$ vcs get datei
** Version 42 von datei ausgecheckt **
$ edit datei
$ vcs send datei "Parameter x auf y gesetzt"
** Version 43 von datei eingechecked, Meldung "Parameter x auf y gesetzt" **

Listing 25.5    Arbeitsablauf bei einem zentralen Versionskontrollsystem

Vor der Bearbeitung wird die aktuelle Version einer Datei geholt. Diese wird bearbeitet, und die bearbeitete Datei wird wieder zurück an das zentrale System gesendet. Die Versionsnummern werden von der zentralen Stelle verwaltet.

25.1.3    Dezentral

Einen der größten Nachteile von zentralen Versionskontrollsystemen, nämlich die Tatsache, dass der zentrale Server immer verfügbar sein muss, beheben dezentrale Versionskontrollsysteme. Sie gelten auch als die zeitgemäße Variante der Versionskontrolle.

Jedes ausgecheckte Repository enthält die komplette Historie aller jemals durchgeführten Änderungen in komprimierter Form. Aus diesem Grund spricht man bei der Kopie auch von Klonen. Unterschiede zwischen Versionen oder zwischen der aktuellen Arbeitskopie und historischen Ständen lassen sich anzeigen, ohne dass eine Verbindung zu einem zentralen Server nötig wäre.

Dieser Vorteil wird allerdings durch einen zusätzlichen Schritt erkauft. Änderungen, die bei zentralen Systemen an einen Server übertragen werden, müssen erst lokal festgeschrieben werden, bevor der aktuelle Stand an den Server übertragen wird (siehe Listing 25.6):

$ vcs fetch
** Synchronisierung von Aenderungen **
$ edit datei
$ vcs send datei "Parameter x auf y gesetzt"
** datei wurde lokal festgeschrieben **
$ vcs transfer
** Alle lokalen Aenderungen an Server uebertragen **

Listing 25.6    Arbeitsablauf dezentrales Versionskontrollsystem

Zunächst beginnt in Listing 25.6 der Arbeitsablauf mit einer Synchronisation des eigenen Repositorys mit dem entfernten. Das ist nicht zwingend nötig, da alle Änderungen auch lokal vorhanden sind, aber es erleichtert das spätere Zusammenführen von Klonen erheblich. Anschließend wird die Datei bearbeitet und lokal festgeschrieben (wobei die Änderung mit einer Meldung versehen wird). In einem letzten Schritt werden alle Änderungen an einen anderen Server oder an ein anderes Repository übertragen.