Versionskontrolle

Systeme zur Versionskontrolle dienen der Dokumentation und Wiederherstellung von Dateien. Dabei ermöglichen es Versionskontrollsysteme Änderungen an beliebigen Dateien - sowohl Text- als auch Binär-Dateien - nachzuvollziehen. Ein Versionskontrollsystem unterscheidet sich nicht nur in der Anwendung sondern auch hinsichtlich der Architektur grundsätzlich von Datensicherungssystemen. Ein effizientes System zur Versionskontrolle ist ein wesentlicher Baustein im Hinblick auf ein wirkungsvolles Konfigurationsmanagement. Eines der ältesten Open-Source Versionskontrollsysteme ist das Source Code Control System (SCCS), das bereits im Jahre 1975 von der Firma AT&T realisiert wurde; gefolgt von dem Revision Control System (RCS), das 1985 von Walter Tichy entwickelt wurde und gleichsam eine Basis für nachfolgende Generationen von Versionskontrollsystemen darstellte.


Versionskontrollsysteme erlauben den Zugriff auf unterschiedliche Revisionen einer Datei. Somit ist es möglich, Modifizierungen zu revidieren, und diese einem Zeitpunkt sowie einer Person zuzuordnen. Eine Versionskontrolle bietet sich dabei prinzipiell für alle Arten von Dateien an, moderne Systeme unterstützen dies. Der Einsatz eines Versionskontrollsystems empfiehlt sich im Besonderen, wenn die Bearbeitung in verteilten Projekten - örtlich oder personell gesehen - erfolgt. Die durch ein Versionskontrollsystem organisierte Menge an Dateien sowie deren zusätzliche Informationen zur Versionierung werden im Allgemeinen als Repository bezeichnet.

Versionskontrollsysteme bieten dem Anwender im Wesentlichen folgende Grundfunktionen:

Dokumentation

Es können Modifizierungen und deren Ursprung mit Hilfe einer Historie und entsprechenden Kommentaren nachvollzogen werden. Dies ist beispielsweise zur Bearbeitung von Fehlersituation in Software-Projekten eine unterstützende Funktion, da genau festgestellt werden kann, wann der Fehler implementiert wurde.

Wiederherstellung

Nachträglich nicht erwünschte Modifizierungen können revidiert werden - eine mächtige Funktion, wenn Veränderungen in komplexen Projekten nicht vorhersehbare Konsequenzen haben und diese dann rückwirkend isoliert und beseitigt werden sollen. Diese Dienste werden von modernen Versionskontrollsystemen nicht nur - wie bei ursprünglichen Systemen wie dem Revision Control System (RCS) - für einzelne Dateien angeboten, sondern auch für aus einer Vielzahl von Dateien bestehende komplexe Projekte, dessen Entwicklung sich damit jederzeit vollständig - auch im Rahmen der Software-Qualitätssicherung - dokumentieren lässt.

Zentrale Versionskontrolle

Bei der Anwendung eines zentralen Versionskontrollsystems wird generell zwischen zwei Datenbeständen unterschieden - das zentrale Repository zur Bereitstellung aller Revisionen und eine lokale Arbeitskopie für den Anwender. Diese Differenzierung deutet auch auf die Client-Server-Architektur von Versionskontrollsystemen hin. Der Server organisiert dabei die Verwaltung des Repositories und kooperiert gleichfalls mit einer oder mehreren Instanzen des Clients. Dessen Aufgabe besteht nicht nur darin, die lokalen Arbeitskopien mit dem Server zu koordinieren, sondern auch die Funktionalität des Versionskontrollsystems dem Anwender zur Verfügung zu stellen.

Das Einstellen von Dateien in das Repository wird auch als Import bezeichnet. Der Begriff Checkout benennt den Vorgang, aus dem Versionskontrollsystem eine komplette Kopie eines Projektes zur lokalen Bearbeitung zu entnehmen. Die Übergabe von neuen Modifizierungen an der lokalen Kopie in das Versionskontrollsystem wird als Commit bezeichnet, wobei ein Add das Hinzufügen neuer Dateien in ein bestehendes Repository meint. Ein Update setzt wie bei einem Commit eine Aktualisierung von lokaler Arbeitskopie und der entsprechenden Datei im Repository um. Als Head wird die aktuellste Revision einer Datei im Repository bezeichnet. Die vom Anwender zuletzt aus dem Repository entnommene Revision wird Base genannt.

Wenn die gleichen Dateien im gleichen Zeitraum durch verschiedene Anwender bearbeitet werden, können sogenannte Konflikte entstehen. Diese müssen mit einem Update vor einem Commit beseitigt werden, wodurch die Modifizierungen aus dem Repository in den lokalen Datenbestand aufgenommen werden. Lokale Modifizierungen können automatisch in das Repository integriert werden, wenn die Bearbeitungen in unterschiedlichen Bereichen einer Datei realisiert wurden. Sofern dies nicht der Fall ist, muss letztendlich der Anwender entscheiden, welche Modifizierungen übernommen und welche verworfen werden sollen.

Erfolgt die Entwicklung eines komplexen Projektes parallel - es arbeiten dabei mehrere Anwender parallel auf einer Datei - legt ein Versionskontrollsystem sogenannte unterschiedliche Branches (auch Entwicklungslinien genannt) an. In diesem Fall spricht man auch davon, dass sich die Äste eines Projektes weitgehend getrennt voneinander entwickeln. Der Ausgangspunkt der Veränderung wird vor der Erstellung eines Branches markiert und eine solche Markierung auch als Tag bezeichnet. Die Erstellung, den Austausch zwischen und die Wiedervereinigung von Branches wird durch ein Versionskontrollsystem unterstützt. Der Vorgang der Wiedervereinigung wird auch als Merging bezeichnet. Dabei unterscheiden sich die Methodik der Unterstützung und die Darstellung von Branches zwischen den verschiedenen Versionskontrollsystemen zum Teil erheblich.

Beispiele für zentrale Versionskontrollsysteme sind:

  • Concurrent Version System (CVS, Open Source),
  • Subversion (Open Source),
  • Perforce (Proprietär),
  • Team Foundation Server (Proprietär),
  • Visual SourceSafe (Proprietär).

Verteilte Versionskontrolle

Dabei hat jeder Anwender sein eigenes Repository, in das dieser dann die entsprechenden Änderungen einpflegt. Da der Zugriff direkt erfolgt, ist dies eine deutlich schnellere Methode im Unterschied zur zentralen Versionskontrolle und natürlich auch frei von Konflikten. Eine weitere Folge ist, dass die Revisionen nicht sichtbar für externe Anwender sind. Mit Hilfe von pull- bzw. push-Operationen erfolgt der wechselseitige Zugriff auf Repositories. Als aufwendiger wird bewertet, dass die bei der zentralen Versionskontrolle transparent zu handhabenden Revisionsnummern durch global eindeutige Hashwerte ersetzt werden müssen. Durch deren Verteilung auf unterschiedliche Systeme kommt es zu einem erhöhten Aufwand bei der Verwaltung der Revisionen.

Beispiele für verteilte Versionskontrollsysteme sind:

  • Git (Open Source),
  • Mercurial (Open Source),
  • Monotone (Open Source),
  • Clear Case (Proprietär),
  • Bitkeeper (Proprietär).

Objektbasierte Versionskontrolle

Diese Art der Versionierung nutzt den objektorientierten Ansatz und stellt die Speicherung von einzelnen Klassen und Methoden - die Objekte - in den Vordergrund. Das Versionskontrollsystem realisiert dabei den Umgang mit verschiedenen Objekttypen - interpretiert sozusagen die Semantik des Inhalts einer Datei. Zur Speicherung wird eine entsprechende Datenbank verwendet.

Beispiele für Objektbasierte Versionskontrollsysteme auf Basis der Programmiersprache Smalltalk sind:

  • Envy (Proprietär),
  • STORE (Proprietär).

Informationen zum Artikel
Deutsch: Versionskontrolle
Englisch: version control - VCS
Veröffentlicht: 08.04.2012
Wörter: 939
Tags: #Analyse
Links: Architektur, Aufwand, Client, Client-Server-Architektur, content