Unter einer Versionsverwaltung versteht man ein System, welches typischerweise in der Softwareentwicklung zur Versionierung und um den gemeinsamen Zugriff auf Quelltexte zu kontrollieren, eingesetzt wird. Hierzu werden alle laufenden Änderungen erfasst und alle Versionsstände der Dateien in einem Archiv mit Zeitstempel und Benutzerkennung gesichert. Die Versionsverwaltung ist eine Form des Variantenmanagements. Die übergreifende Disziplin ist das Software Configuration Management (SCM).
Es wird sichergestellt, dass jeder Benutzer mit dem aktuellen Stand arbeitet oder auf Wunsch auf die archivierten Stände zugreifen kann. Dadurch ist eine Versionsverwaltung nicht nur für professionelle Entwickler in großen Teams, sondern auch für einzelne Entwickler interessant. Es kann jederzeit eine ältere Version aufgerufen werden, falls eine Änderung nicht funktioniert und man sich nicht mehr sicher ist, was nun alles geändert wurde.
Ein Beispiel ist auch die Wikipedia: Hier erzeugt die Software nach jeder Änderung eines Artikels eine neue Version. Da zu jedem Versionswechsel die grundlegenden Angaben wie Verfasser und Uhrzeit festgehalten werden, kann jeder genau nachvollziehen, wer wann was geändert hat. Bei Bedarf – beispielsweise bei versehentlichen Änderungen – kann man zu einer früheren Version zurückkehren.
Auch in technischen Zeichnungen werden Versionen zum Beispiel durch einen Änderungsindex verwaltet.
Für Versionsverwaltungssysteme sind die Abkürzungen VCS (Version Control System) oder SCM (Source Code/Control Managementsystem) gebräuchlich.
Systemaufbau
Das zentrale Archiv wird als Repository (engl. Behälter, Aufbewahrungsort) bezeichnet. Die meisten Systeme verwenden hierfür ein eigenes Dateiformat (oder eine Datenbank). Die Versionsverwaltungssoftware speichert dabei üblicherweise nur die Unterschiede zwischen zwei Versionen, um Speicherplatz zu sparen. 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. Solche Software ist häufig als Client-Server-System aufgebaut, sodass der Zugriff auf ein Repository auch über Netzwerk erfolgen kann.
Theoretisch lässt sich jedes Dokument versionieren. In der Praxis jedoch werden die komplizierten Verfahren der Versionskontrolle nur selten außerhalb der Softwareentwicklung eingesetzt. Damit die in der Softwareentwicklung eingesetzten Programme wie z. B. Compiler mit den im Repository 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 oder Aktualisieren bezeichnet, während die umgekehrte Übertragung Check-in oder Commit genannt wird. Solche Programme sind 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.
Hauptaufgaben eines Versionsverwaltungssystems
- 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 Release-Stände eines Projektes: Dadurch ist es jederzeit möglich auf alle ausgelieferten Versionen zuzugreifen.
- Koordinierung des gemeinsamen Zugriffs von mehreren Entwicklern auf die Dateien
- Gleichzeitige Entwicklung mehrerer Entwicklungszweige (engl. Branches) eines Projektes (z. B. stabile Release-Version und Entwicklerversion mit größeren, nicht getesteten Änderungen): Hier wird der Entwickler bei der Übernahme von einzelnen Änderungen zwischen den Zweigen und der Hauptversion unterstützt.
Arbeitsweisen der Versionsverwaltung
Lock Modify Write
Dies ist die traditionelle Arbeitsweise eines Versionsverwaltungssystems und wird auch als Lock Modify Unlock bezeichnet. Die zugrundeliegende Philosophie wird auch Pessimistic Revision Control (engl., Pessimistische Versionskontrolle) 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 anderer Benutzer. Bekanntester und ältester Vertreter dieser Arbeitsweise ist das Revision Control System (kurz: RCS) von Walter F. Tichy.
Copy Modify Merge
Ein solches System lässt gleichzeitige Änderungen mehrerer 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 mehrere Entwickler räumlich getrennt arbeiten, wie es beispielsweise bei Open-Source Projekten der Fall ist, ermöglicht dies deutlich flüssigeres Arbeiten. Die zugrundeliegende Philosophie wird als Optimistic Revision Control (engl., Optimistische Versionskontrolle) bezeichnet und wurde entwickelt um die Schwächen der Pessimistic Revision Control (engl., Pessimistische Versionskontrolle) zu beheben. Bekanntester Vertreter ist das Concurrent Versions System (kurz: CVS). Subversion (kurz: SVN) wurde als Alternative und zur Ablösung von CVS entwickelt.
Branching und Tagging
Die Entwicklung komplexer Software erfordert fast zwangsläufig eine Strategie von Branching und Tagging:
- vor komplexen Änderungen erzeugt man einen sog. Branch, also eine Verzweigung, auf der die Entwicklung fortgesetzt wird, bis die komplexe Änderung fertig ist; dabei kann auf diesem Branch committet werden, ohne dass die Hauptentwicklungslinie (der sog. Trunk) davon beeinflusst wird. Abschließend erfolgt üblicherweise die Reintegration in den Trunk, der sog. Merge
- ein Tag kennzeichnet einen konkreten Entwicklungsstand, z. B. eine zur Auslieferung bestimmte Version; er erhält einen Namen, über den er später noch verfügbar ist. Auf einem Tag finden keine Änderungen statt; stattdessen erzeugt man für einen neuen Versionsstand ein neues Tag.
Siehe auch
- SCCS
- Git
- Mercurial
- Bazaar
- ClearCase
- Visual SourceSafe
- Versionsverwaltung beim Dokumentenmanagement