Versionsverwaltung

• Protokollierungen der Änderungen: Es kann jederzeit nachvollzogen werden, wer wann was geändert hat.
• Wiederherstellung von alten Ständen einzelner Dateien: Somit können versehentliche Änderungen jederzeit wieder rückgängig gemacht werden.
• Archivierung der einzelnen Stände eines Projektes: Dadurch ist es jederzeit möglich, auf alle Versionen zuzugreifen.
• Koordinierung des gemeinsamen Zugriffs von mehreren Entwicklern auf die Dateien.
• Gleichzeitige Entwicklung mehrerer Entwicklungszweige (engl. Branch) eines Projektes, was nicht mit der Abspaltung eines anderen Projekts (engl. Fork) verwechselt werden darf.

Ein Branch, zu deutsch Zweig, ist eine Verzweigung zu einer neuen Version, so dass unterschiedliche Versionen parallel im selben Projekt weiterentwickelt werden können. Änderungen können dabei von einem Branch auch wieder in einen anderen einfließen, was als Merging, zu deutsch verschmelzen, bezeichnet wird. Oft wird der Hauptentwicklungszweig als Trunk (z. B. bei Subversion) oder Main (ehemals Master) (z. B. bei Git) bezeichnet. Branches können zum Beispiel für neue Hauptversionen einer Software erstellt werden oder für Entwicklungszweige für unterschiedliche Betriebssysteme oder aber auch, um experimentelle Versionen zu erproben. Wird ein Zweig in einer neuen, unabhängigen Versionsverwaltung erstellt, spricht man von einem Fork. Ein bestimmter Stand kann auch mit einem Tag (einem frei wählbaren Bezeichner) gekennzeichnet werden.

Damit die eingesetzten Programme wie z. B. Texteditoren oder Compiler mit den im Repository (engl. Behälter, Aufbewahrungsort) abgelegten Dateien arbeiten können, ist es erforderlich, dass jeder Entwickler sich den aktuellen (oder einen älteren) Stand des Projektes in Form eines Verzeichnisbaumes aus herkömmlichen Dateien erzeugen kann. Ein solcher Verzeichnisbaum wird als Arbeitskopie bezeichnet. Ein wichtiger Teil des Versionsverwaltungssystems ist ein Programm, das in der Lage ist, diese Arbeitskopie mit den Daten des Repositorys zu synchronisieren. Das Übertragen einer Version aus dem Repository in die Arbeitskopie wird als Checkout, Aus-Checken oder Aktualisieren bezeichnet, während die umgekehrte Übertragung Check-in, Einchecken oder Commit genannt wird. Solche Programme werden entweder kommandozeilenorientiert, mit grafischer Benutzeroberfläche oder als Plugin für integrierte Softwareentwicklungsumgebungen ausgeführt. Häufig werden mehrere dieser verschiedenen Zugriffsmöglichkeiten wahlweise bereitgestellt.

Es gibt drei Arten der Versionsverwaltung, die älteste funktioniert lokal, also nur auf einem Computer, die nächste Generation funktionierte mit einem zentralen Archiv und die neueste Generation arbeitet verteilt, also ohne zentrales Archiv. Allen gemein ist, dass die Versionsverwaltungssoftware dabei üblicherweise nur die Unterschiede zwischen zwei Versionen speichert, um Speicherplatz zu sparen. Die meisten Systeme verwenden hierfür ein eigenes Dateiformat oder eine Datenbank. Dadurch kann eine große Zahl von Versionen archiviert werden. Durch dieses Speicherformat kann jedoch nur mit der Software des Versionsverwaltungssystems auf die Daten zugegriffen werden, die die gewünschte Version bei einem Abruf unmittelbar aus den archivierten Versionen rekonstruiert.

Bei der lokalen Versionsverwaltung wird oft nur eine einzige Datei versioniert, diese Variante wurde mit Werkzeugen wie SCCS und RCS umgesetzt. Sie findet auch heute noch Verwendung in Büroanwendungen, die Versionen eines Dokumentes in der Datei des Dokuments selbst speichern. Auch in technischen Zeichnungen werden Versionen zum Beispiel durch einen Änderungsindex verwaltet.

Diese Art ist als Client-Server-System aufgebaut, sodass der Zugriff auf ein Repository auch über Netzwerk erfolgen kann. Durch eine Rechteverwaltung wird dafür gesorgt, dass nur berechtigte Personen neue Versionen in das Archiv legen können. Die Versionsgeschichte ist hierbei nur im Repository vorhanden. Dieses Konzept wurde vom Open-Source-Projekt Concurrent Versions System (CVS) populär gemacht, mit Subversion (SVN) neu implementiert und von vielen kommerziellen Anbietern verwendet.

Die verteilte Versionsverwaltung (DVCS, distributed VCS) verwendet kein zentrales Repository mehr. Jeder, der an dem verwalteten Projekt arbeitet, hat sein eigenes Repository und kann dieses mit jedem beliebigen anderen Repository abgleichen. Die Versionsgeschichte ist dadurch genauso verteilt. Änderungen können lokal verfolgt werden, ohne eine Verbindung zu einem Server aufbauen zu müssen.

Im Gegensatz zur zentralen Versionsverwaltung kommt es nicht zu einem Konflikt, wenn mehrere Benutzer dieselbe Version einer Datei ändern. Die sich widersprechenden Versionen existieren zunächst parallel und können weiter geändert werden. Sie können später in eine neue Version zusammengeführt werden. Dadurch entsteht ein gerichteter azyklischer Graph (Polyhierarchie) anstatt einer Kette von Versionen. In der Praxis werden bei der Verwendung in der Softwareentwicklung meist einzelne Features oder Gruppen von Features in separaten Versionen entwickelt und diese bei größeren Projekten von Personen mit einer Integrator-Rolle überprüft und zusammengeführt.

Systembedingt bieten verteilte Versionsverwaltungen keine Locks. Da wegen der höheren Zugriffsgeschwindigkeit die Granularität der gespeicherten Änderungen viel kleiner sein kann, können sie sehr leistungsfähige, weitgehend automatische Merge-Mechanismen zur Verfügung stellen.

Eine Unterart der Versionsverwaltung bieten einfachere Patchverwaltungssysteme, die Änderungen nur in eine Richtung in Produktivsysteme einspeisen.

Obwohl konzeptionell nicht unbedingt notwendig, existiert in verteilten Versionsverwaltungsszenarien üblicherweise ein offizielles Repository. Das offizielle Repository wird von neuen Projektbeteiligten zu Beginn ihrer Arbeit geklont, d. h. auf das lokale System kopiert.

Diese Arbeitsweise eines Versionsverwaltungssystems wird auch als Lock Modify Unlock bezeichnet. Die zugrunde liegende Philosophie wird pessimistische Versionsverwaltung genannt. Einzelne Dateien müssen vor einer Änderung durch den Benutzer gesperrt und nach Abschluss der Änderung wieder freigegeben werden. Während sie gesperrt sind, verhindert das System Änderungen durch andere Benutzer. Der Vorteil dieses Konzeptes ist, dass kein Zusammenführen von Versionen erforderlich ist, da nur immer ein Entwickler eine Datei ändern kann. Der Nachteil ist, dass man unter Umständen auf die Freigabe eines Dokuments warten muss, um eine eigene Änderung einzubringen. Zu beachten ist, dass Binärdateien (im Gegensatz zu Quelltextdateien) in der Regel diese Arbeitsweise erfordern, da das Versionsverwaltungssystem verteilte Änderungen nicht automatisch synchronisieren kann. Ältester Vertreter dieser Arbeitsweise ist das Revision Control System, ebenso bekannt ist Visual SourceSafe. Verteilte Versionsverwaltungssysteme kennen systembedingt diese Arbeitsweise nicht.

Ein solches System lässt gleichzeitige Änderungen durch mehrere Benutzer an einer Datei zu. Anschließend werden diese Änderungen automatisch oder manuell zusammengeführt (Merge). Somit wird die Arbeit des Entwicklers wesentlich erleichtert, da Änderungen nicht im Voraus angekündigt werden müssen. Insbesondere wenn viele Entwickler räumlich getrennt arbeiten, wie es beispielsweise bei Open-Source-Projekten häufig der Fall ist, ermöglicht dies erst effizientes Arbeiten, da kein direkter Kontakt zwischen den Entwicklern benötigt wird. Problematisch bei diesem System sind Binärdateien, da diese oft nicht automatisch zusammengeführt werden können, sofern kein passendes Werkzeug verfügbar ist. Manche Vertreter dieser Gattung unterstützen daher auch alternativ das Lock-Modify-Write-Konzept für bestimmte Dateien.

Die zugrunde liegende Philosophie wird als optimistische Versionsverwaltung bezeichnet und wurde entwickelt, um die Schwächen der pessimistischen Versionsverwaltung zu beheben. Alle modernen zentralen und verteilten Systeme setzen dieses Verfahren um.

Über die Grenze des abspeichernden Mediums, der Datei, hinaus geht die Objekt-basierte Versionierung. Objekte werden in der Informatik als sogenannte Instanzen, also Ausprägungen eines Schemas, erzeugt. Auch diese können versioniert gespeichert werden. Die Versionsverwaltung, welche die unterschiedlichen Objektversionen abspeichert, muss mit den entsprechenden Objekttypen umgehen können. Aus dem Grund liest ein solches System nicht allein die Datei und überprüft diese auf Veränderungen, sondern kann die darin enthaltene Semantik interpretieren. Üblicherweise werden Objekte dann nicht dateibasiert, sondern in einer Datenbank abgespeichert. Produktdatenmanagement-Systeme (PDM-Systeme) verwalten ihre Daten nach diesem Prinzip.

Die folgende Tabelle enthält einige Versionsverwaltungssysteme als Beispiele für die verschiedenen Ausprägungsarten.

• Versionsnummer
• Versionshinweise
• Source Code Control System
• Dokumentenmanagement
• Logdatei

• Vergleich von SVN, Git, Mercurial und CVS (englisch)
• Liste von Versionverwaltungssystemen speziell für Linux (englisch, 2004)
• Versionskontrollsysteme in der Softwareentwicklung (2005; PDF; 790 kB)
• Verteilte Versionskontrollsysteme (2009), CRE
• Einführung in Verteilte Versionsverwaltung (englisch)
• Semantic Versioning