Versionsverwaltung

In der Softwaretechnik ist die Versionskontrolle (auch als Revisionskontrolle, Quellcodekontrolle oder Quellcodeverwaltung bekannt) eine Klasse von Systemen, die für die Verwaltung von Änderungen an Computerprogrammen, Dokumenten, großen Websites oder anderen Informationssammlungen zuständig sind. Die Versionskontrolle ist eine Komponente des Software-Konfigurationsmanagements. ⓘ

Änderungen werden in der Regel durch eine Nummer oder einen Buchstabencode gekennzeichnet, die als "Revisionsnummer", "Revisionsstufe" oder einfach "Revision" bezeichnet werden. Ein erster Satz von Dateien ist beispielsweise "Revision 1". Wenn die erste Änderung vorgenommen wird, ist der resultierende Satz "Revision 2" usw. Jede Revision ist mit einem Zeitstempel und der Person, die die Änderung vorgenommen hat, versehen. Revisionen können verglichen, wiederhergestellt und bei einigen Dateitypen auch zusammengeführt werden. ⓘ

Das Bedürfnis nach einer logischen Art und Weise, Revisionen zu organisieren und zu kontrollieren, besteht schon fast so lange, wie es das Schreiben gibt, aber die Revisionskontrolle wurde viel wichtiger und komplizierter, als die Ära der Computer begann. Die Nummerierung von Buchausgaben und Revisionen von Spezifikationen sind Beispiele, die noch aus dem reinen Druckzeitalter stammen. Heute werden die leistungsfähigsten (und komplexesten) Versionskontrollsysteme in der Softwareentwicklung eingesetzt, wo ein Team von Mitarbeitern gleichzeitig Änderungen an denselben Dateien vornehmen kann. ⓘ

Versionskontrollsysteme werden meist als eigenständige Anwendungen betrieben, aber die Versionskontrolle ist auch in verschiedene Arten von Software eingebettet, z. B. in Textverarbeitungsprogramme und Tabellenkalkulationen, kollaborative Webdokumente und Inhaltsverwaltungssysteme, z. B. die Seitenhistorie von Wikipedia. Die Revisionskontrolle ermöglicht es, ein Dokument auf eine frühere Version zurückzusetzen, was wichtig ist, damit die Redakteure die Änderungen der anderen verfolgen, Fehler korrigieren und sich gegen Vandalismus und Spamming in Wikis schützen können. ⓘ

Eine Versionsverwaltung ist ein System, das zur Erfassung von Änderungen an Dokumenten oder Dateien verwendet wird. Alle Versionen werden in einem Archiv mit Zeitstempel und Benutzerkennung gesichert und können später wiederhergestellt werden. Versionsverwaltungssysteme werden typischerweise in der Softwareentwicklung eingesetzt, um Quelltexte zu verwalten. Versionsverwaltung kommt auch bei Büroanwendungen oder Content-Management-Systemen zum Einsatz. ⓘ

Ein Beispiel ist die Protokollierung in vielen Wikis: hier erzeugt die Software nach jeder Änderung eines Artikels eine neue Version. Alle Versionen bilden eine Kette, in der die jeweils letzte Version gültig ist; es sind meist keine Varianten vorgesehen. Da zu jedem Versionswechsel die grundlegenden Angaben wie Verfasser und Uhrzeit festgehalten werden, kann genau nachvollzogen werden, wer wann was geändert hat. Bei Bedarf – beispielsweise bei versehentlichen Änderungen – kann man zu einer früheren Version zurückkehren. ⓘ

Die Versionsverwaltung ist eine Form des Variantenmanagements; dort sind verschiedene Sprachvarianten oder modal auch anders bestimmte Varianten möglich. Für Versionsverwaltungssysteme ist die Abkürzung VCS (Version Control System) gebräuchlich. ⓘ

Überblick

In der Computersoftwaretechnik ist Revisionskontrolle jede Art von Praxis, die Änderungen am Quellcode verfolgt und kontrolliert. Softwareentwickler verwenden manchmal Revisionskontrollsoftware, um Dokumentation und Konfigurationsdateien sowie den Quellcode zu verwalten. ⓘ

Wenn Teams Software entwerfen, entwickeln und bereitstellen, ist es üblich, dass mehrere Versionen derselben Software an verschiedenen Standorten bereitgestellt werden und dass die Softwareentwickler gleichzeitig an Aktualisierungen arbeiten. Fehler oder Funktionen der Software sind oft nur in bestimmten Versionen vorhanden (weil einige Probleme behoben und andere im Zuge der Weiterentwicklung des Programms eingeführt wurden). Daher ist es für die Fehlersuche und -behebung von entscheidender Bedeutung, verschiedene Versionen der Software abrufen und ausführen zu können, um festzustellen, in welcher(n) Version(en) das Problem auftritt. Es kann auch notwendig sein, zwei Versionen der Software gleichzeitig zu entwickeln: z.B. eine Version, in der Fehler behoben sind, aber keine neuen Funktionen (Branch), während in der anderen Version an neuen Funktionen gearbeitet wird (Trunk). ⓘ

Auf der einfachsten Ebene könnten die Entwickler einfach mehrere Kopien der verschiedenen Versionen des Programms aufbewahren und sie entsprechend kennzeichnen. Dieser einfache Ansatz wurde bereits in vielen großen Softwareprojekten verwendet. Diese Methode kann zwar funktionieren, ist aber ineffizient, da viele nahezu identische Kopien des Programms beibehalten werden müssen. Dies erfordert von den Entwicklern ein hohes Maß an Selbstdisziplin und führt häufig zu Fehlern. Da die Codebasis dieselbe ist, müssen außerdem Lese-, Schreib- und Ausführungsberechtigungen für eine Reihe von Entwicklern erteilt werden, was den Druck erhöht, dass jemand die Berechtigungen verwaltet, damit die Codebasis nicht gefährdet wird, was die Komplexität noch erhöht. Daher wurden Systeme entwickelt, die den Prozess der Revisionskontrolle ganz oder teilweise automatisieren. Dadurch wird sichergestellt, dass der größte Teil der Versionskontrollschritte im Verborgenen stattfindet. ⓘ

Darüber hinaus ist es in der Softwareentwicklung, in der Rechts- und Geschäftspraxis und in anderen Umgebungen immer häufiger der Fall, dass ein einzelnes Dokument oder ein Codeschnipsel von einem Team bearbeitet wird, dessen Mitglieder geografisch verstreut sein und unterschiedliche oder sogar gegensätzliche Interessen verfolgen können. Eine ausgefeilte Revisionskontrolle, die Änderungen an Dokumenten und Code nachverfolgt und berücksichtigt, kann in solchen Situationen äußerst hilfreich oder sogar unverzichtbar sein. ⓘ

Die Revisionskontrolle kann auch Änderungen an Konfigurationsdateien nachverfolgen, wie sie beispielsweise in /etc oder /usr/local/etc auf Unix-Systemen gespeichert sind. Damit haben Systemadministratoren eine weitere Möglichkeit, Änderungen leicht nachzuvollziehen und bei Bedarf zu früheren Versionen zurückzukehren. ⓘ

Verlauf

Das IBM OS/360 IEBUPDTE Software-Update-Tool geht auf das Jahr 1962 zurück und war wohl ein Vorläufer der Versionskontrollsysteme. Ein vollständiges System für die Quellcodekontrolle wurde 1972 eingeführt, das Source Code Control System für dasselbe System (OS/360). Die Einführung von Source Code Control System, die am 4. Dezember 1975 veröffentlicht wurde, war historisch gesehen das erste bewusste Revisionskontrollsystem. RCS folgte kurz darauf mit seiner vernetzten Version Concurrent Versions System. Die nächste Generation nach Concurrent Versions System wurde von Subversion dominiert, gefolgt vom Aufstieg verteilter Revisionskontrollwerkzeuge wie Git. ⓘ

Aufbau

Die Revisionskontrolle verwaltet Änderungen an einem Datensatz im Laufe der Zeit. Diese Änderungen können auf verschiedene Weise strukturiert werden. ⓘ

Häufig werden die Daten als eine Sammlung vieler einzelner Elemente, wie Dateien oder Dokumente, betrachtet, und die Änderungen an einzelnen Dateien werden verfolgt. Dies entspricht der Intuition von getrennten Dateien, führt aber zu Problemen, wenn sich die Identität ändert, z. B. bei der Umbenennung, Aufteilung oder Zusammenführung von Dateien. Dementsprechend betrachten einige Systeme, wie z. B. Git, stattdessen Änderungen an den Daten als Ganzes, was bei einfachen Änderungen weniger intuitiv ist, aber komplexere Änderungen vereinfacht. ⓘ

Wenn Daten, die unter Revisionskontrolle stehen, geändert werden, nachdem sie durch Auschecken abgerufen wurden, wird dies im Allgemeinen nicht sofort im Revisionskontrollsystem (im Repository) reflektiert, sondern muss eingecheckt oder committed werden. Eine Kopie außerhalb der Revisionskontrolle wird als "Arbeitskopie" bezeichnet. Ein einfaches Beispiel: Bei der Bearbeitung einer Computerdatei sind die vom Bearbeitungsprogramm im Speicher abgelegten Daten die Arbeitskopie, die durch Speichern übertragen wird. Konkret kann man ein Dokument ausdrucken, es von Hand bearbeiten und erst später die Änderungen manuell in einen Computer eingeben und speichern. Bei der Quellcodekontrolle ist die Arbeitskopie stattdessen eine Kopie aller Dateien in einer bestimmten Revision, die in der Regel lokal auf dem Computer des Entwicklers gespeichert ist; in diesem Fall wird durch das Speichern der Datei nur die Arbeitskopie geändert, und das Einchecken in das Projektarchiv ist ein separater Schritt. ⓘ

Wenn mehrere Personen an einem einzigen Datensatz oder Dokument arbeiten, erstellen sie implizit Zweige der Daten (in ihren Arbeitskopien), wodurch sich Probleme bei der Zusammenführung ergeben, wie unten beschrieben. Bei der einfachen gemeinsamen Bearbeitung von Dokumenten kann dies durch die Verwendung von Dateisperren oder einfach durch die Vermeidung der Arbeit an demselben Dokument, an dem jemand anderes arbeitet, verhindert werden. ⓘ

Revisionskontrollsysteme sind oft zentralisiert, mit einem einzigen maßgeblichen Datenspeicher, dem Repository, und Check-Outs und Check-Ins werden unter Bezugnahme auf dieses zentrale Repository durchgeführt. Bei der verteilten Revisionskontrolle hingegen ist kein einziges Repository maßgebend, und die Daten können in jedes beliebige Repository ein- und ausgecheckt werden. Beim Einchecken in ein anderes Repository wird dies als Merge oder Patch interpretiert. ⓘ

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. ⓘ

Struktur des Graphen

Beispiel für den Verlaufsgraphen eines revisionskontrollierten Projekts; der Stamm ist grün, die Zweige sind gelb, und der Graph ist kein Baum, weil es Zusammenführungen gibt (die roten Pfeile). ⓘ

In der Graphentheorie stellt man sich Revisionen im Allgemeinen als eine Entwicklungslinie (den Stamm) mit davon abzweigenden Zweigen vor, die einen gerichteten Baum bilden, visualisiert als eine oder mehrere parallele Entwicklungslinien (die "Hauptlinien" der Zweige), die von einem Stamm abzweigen. In Wirklichkeit ist die Struktur komplizierter und bildet einen gerichteten azyklischen Graphen, aber für viele Zwecke ist "Baum mit Zusammenführungen" eine angemessene Annäherung. ⓘ

Revisionen erfolgen in zeitlicher Abfolge und können daher entweder nach Revisionsnummer oder Zeitstempel geordnet werden. Revisionen basieren auf früheren Revisionen, wobei es möglich ist, eine frühere Revision weitgehend oder vollständig zu ersetzen, z. B. "allen vorhandenen Text löschen, neuen Text einfügen". Im einfachsten Fall, ohne Verzweigung oder Rückgängigmachung, basiert jede Revision allein auf ihrem unmittelbaren Vorgänger, und sie bilden eine einfache Linie mit einer einzigen letzten Version, der "HEAD"-Revision oder Spitze. Aus Sicht der Graphentheorie ist dies ein linearer Graph, wenn man jede Revision als Punkt und jede Beziehung zwischen "abgeleiteten Revisionen" als Pfeil zeichnet (der üblicherweise von der älteren zur neueren Version zeigt, in der gleichen Richtung wie die Zeit). Wenn es eine Verzweigung gibt, so dass mehrere zukünftige Revisionen auf einer vergangenen Revision basieren, oder eine Rückgängigmachung, so dass eine Revision von einer Revision abhängen kann, die älter als ihr unmittelbarer Vorgänger ist, dann ist der resultierende Graph stattdessen ein gerichteter Baum (jeder Knoten kann mehr als ein Kind haben) und hat mehrere Spitzen, die den Revisionen ohne Kinder entsprechen ("letzte Revision auf jedem Zweig"). Im Prinzip muss der resultierende Baum keine bevorzugte Spitze ("wichtigste" letzte Revision) haben - nur verschiedene Revisionen - aber in der Praxis wird eine Spitze im Allgemeinen als HEAD identifiziert. Wenn eine neue Revision auf HEAD basiert, wird sie entweder als neuer HEAD identifiziert oder als neuer Zweig betrachtet. Die Liste der Revisionen vom Anfang bis zum HEAD (im Sinne der Graphentheorie der einzige Pfad im Baum, der wie zuvor einen linearen Graphen bildet) ist der Stamm oder die Hauptlinie. Umgekehrt, wenn eine Revision auf mehr als einer vorherigen Revision basieren kann (wenn ein Knoten mehr als einen Elternteil haben kann), wird der daraus resultierende Prozess als Zusammenführung bezeichnet und ist einer der komplexesten Aspekte der Revisionskontrolle. Dies geschieht am häufigsten, wenn Änderungen in mehreren Zweigen (meist zwei, aber auch mehr sind möglich) auftreten, die dann zu einem einzigen Zweig zusammengeführt werden, der beide Änderungen enthält. Wenn sich diese Änderungen überschneiden, kann es schwierig oder unmöglich sein, sie zusammenzuführen, und erfordert einen manuellen Eingriff oder ein Neuschreiben. ⓘ

Beim Vorhandensein von Zusammenführungen ist der resultierende Graph kein Baum mehr, da Knoten mehrere Eltern haben können, sondern ein verwurzelter gerichteter azyklischer Graph (DAG). Der Graph ist azyklisch, da die Eltern in der Zeit immer rückwärts laufen, und verwurzelt, da es eine älteste Version gibt. Unter der Annahme, dass es einen Stamm gibt, können Zusammenführungen von Zweigen als "extern" zum Baum betrachtet werden - die Änderungen im Zweig werden als Patch verpackt, der auf HEAD (des Stammes) angewendet wird, wodurch eine neue Revision ohne expliziten Bezug auf den Zweig entsteht und die Baumstruktur erhalten bleibt. Während also die tatsächlichen Beziehungen zwischen den Versionen ein DAG bilden, kann dies als Baum plus Zusammenführungen betrachtet werden, und der Stamm selbst ist eine Linie. ⓘ

Bei der verteilten Revisionskontrolle können diese bei Vorhandensein mehrerer Repositories auf einer einzigen ursprünglichen Version (einer Wurzel des Baums) basieren, aber es muss keine ursprüngliche Wurzel und somit nur eine separate Wurzel (älteste Revision) für jedes Repository geben, z. B. wenn zwei Personen getrennt mit der Arbeit an einem Projekt beginnen. Auch bei mehreren Datensätzen (mehreren Projekten), die Daten austauschen oder zusammengeführt werden, gibt es keine einzige Wurzel, obwohl man der Einfachheit halber ein Projekt als primär und das andere als sekundär betrachten kann, das mit dem ersten zusammengeführt wird, mit oder ohne eigene Revisionsgeschichte. ⓘ

Spezialisierte Strategien

Die Revisionskontrolle im Ingenieurwesen entwickelte sich aus formalisierten Prozessen, die auf der Verfolgung von Revisionen früherer Entwürfe oder Blaupausen basierten. Dieses Kontrollsystem ermöglichte implizit die Rückkehr zu einem früheren Stand des Entwurfs, wenn die Entwicklung des Entwurfs in eine Sackgasse geraten war. Eine Revisionstabelle wurde verwendet, um die vorgenommenen Änderungen zu erfassen. Zusätzlich wurden die geänderten Bereiche der Zeichnung durch Revisionswolken hervorgehoben. ⓘ

Die Versionskontrolle ist in Wirtschaft und Recht weit verbreitet. Der "rote Faden im Vertrag" und der "schwarze Faden im Gesetz" gehören zu den frühesten Formen der Versionskontrolle und werden in Wirtschaft und Recht immer noch in unterschiedlichem Ausmaß eingesetzt. Die ausgefeiltesten Techniken werden allmählich für die elektronische Verfolgung von Änderungen an CAD-Dateien eingesetzt (siehe Produktdatenmanagement) und ersetzen die "manuelle" elektronische Umsetzung der traditionellen Revisionskontrolle. ⓘ

Modelle der Versionsverwaltung

Traditionelle Revisionskontrollsysteme verwenden ein zentralisiertes Modell, bei dem alle Revisionskontrollfunktionen auf einem gemeinsamen Server stattfinden. Wenn zwei Entwickler versuchen, dieselbe Datei zur gleichen Zeit zu ändern, kann es ohne eine Methode zur Verwaltung des Zugriffs dazu kommen, dass die Entwickler die Arbeit des anderen überschreiben. Zentralisierte Revisionskontrollsysteme lösen dieses Problem mit einem von zwei verschiedenen "Quellverwaltungsmodellen": Dateisperren und Versionszusammenführung. ⓘ

Atomare Operationen

Eine Operation ist atomar, wenn das System in einem konsistenten Zustand verbleibt, auch wenn die Operation unterbrochen wird. Die Commit-Operation ist normalerweise die kritischste in diesem Sinne. Commits weisen das Revisionskontrollsystem an, eine Gruppe von Änderungen endgültig und für alle Benutzer verfügbar zu machen. Nicht alle Revisionskontrollsysteme verfügen über atomare Commits; Concurrent Versions System hat diese Funktion nicht. ⓘ

Dateisperren

Die einfachste Methode, um Probleme mit dem "gleichzeitigen Zugriff" zu verhindern, besteht darin, Dateien zu sperren, so dass jeweils nur ein Entwickler Schreibzugriff auf die zentralen "Repository"-Kopien dieser Dateien hat. Sobald ein Entwickler eine Datei "auscheckt", können andere diese Datei lesen, aber kein anderer kann diese Datei ändern, bis dieser Entwickler die aktualisierte Version "eincheckt" (oder das Auschecken abbricht). ⓘ

Die Dateisperre hat sowohl Vor- als auch Nachteile. Es kann einen gewissen Schutz gegen schwierige Merge-Konflikte bieten, wenn ein Benutzer radikale Änderungen an vielen Abschnitten einer großen Datei (oder einer Gruppe von Dateien) vornimmt. Wenn die Dateien zu lange exklusiv gesperrt bleiben, könnten andere Entwickler versucht sein, die Revisionskontrollsoftware zu umgehen und die Dateien lokal zu ändern, was einen schwierigen manuellen Zusammenschluss erzwingt, wenn die anderen Änderungen schließlich eingecheckt werden. In einer großen Organisation können Dateien "ausgecheckt" und gesperrt bleiben und in Vergessenheit geraten, wenn Entwickler zwischen Projekten wechseln - mit diesen Werkzeugen ist es nicht immer einfach zu sehen, wer eine Datei ausgecheckt hat. ⓘ

Zusammenführen von Versionen

Die meisten Versionskontrollsysteme erlauben es mehreren Entwicklern, dieselbe Datei gleichzeitig zu bearbeiten. Der erste Entwickler, der Änderungen in das zentrale Repository "eincheckt", ist immer erfolgreich. Das System kann die Möglichkeit bieten, weitere Änderungen in das zentrale Repository einzubringen und die Änderungen des ersten Entwicklers zu erhalten, wenn andere Entwickler einchecken. ⓘ

Das Zusammenführen von zwei Dateien kann eine sehr heikle Operation sein und ist normalerweise nur möglich, wenn die Datenstruktur einfach ist, wie bei Textdateien. Das Ergebnis einer Zusammenführung von zwei Bilddateien könnte überhaupt keine Bilddatei ergeben. Der zweite Entwickler, der den Code überprüft, muss bei der Zusammenführung darauf achten, dass die Änderungen kompatibel sind und dass die Zusammenführung keine eigenen logischen Fehler in die Dateien einführt. Diese Probleme beschränken die Verfügbarkeit von automatischen oder halbautomatischen Zusammenführungsoperationen hauptsächlich auf einfache textbasierte Dokumente, es sei denn, ein spezielles Zusammenführungs-Plugin ist für die Dateitypen verfügbar. ⓘ

Das Konzept des reservierten Editierens kann ein optionales Mittel sein, um eine Datei explizit für den exklusiven Schreibzugriff zu sperren, auch wenn eine Zusammenführungsmöglichkeit besteht. ⓘ

Grundlinien, Labels und Tags

Die meisten Werkzeuge zur Revisionskontrolle verwenden nur einen dieser ähnlichen Begriffe (Baseline, Label, Tag), um sich auf die Aktion der Identifizierung eines Schnappschusses ("label the project") oder die Aufzeichnung des Schnappschusses ("try it with baseline X") zu beziehen. In der Regel wird nur einer der Begriffe Baseline, Label oder Tag in der Dokumentation oder Diskussion verwendet; sie können als Synonyme betrachtet werden. ⓘ

In den meisten Projekten sind einige Snapshots aussagekräftiger als andere, wie z.B. die, die zur Kennzeichnung von veröffentlichten Versionen, Zweigen oder Meilensteinen verwendet werden. ⓘ

Wenn die Begriffe "Baseline" und "Label" oder "Tag" im gleichen Kontext verwendet werden, beziehen sich "Label" und "Tag" in der Regel auf den Mechanismus innerhalb des Tools, mit dem der Snapshot identifiziert oder aufgezeichnet wird, und "Baseline" weist auf die erhöhte Bedeutung eines bestimmten Labels oder Tags hin. ⓘ

In den meisten formalen Diskussionen über das Konfigurationsmanagement wird der Begriff Baseline verwendet. ⓘ

Verteilte Revisionskontrolle

Verteilte Revisionskontrollsysteme (DRCS) verfolgen einen Peer-to-Peer-Ansatz, im Gegensatz zum Client-Server-Ansatz zentralisierter Systeme. Anstelle eines einzigen zentralen Repositorys, mit dem sich die Clients synchronisieren, ist die Arbeitskopie der Codebasis jedes Peers ein echtes Repository. Bei der verteilten Revisionskontrolle erfolgt die Synchronisierung durch den Austausch von Patches (Change-Sets) von Peer zu Peer. Daraus ergeben sich einige wichtige Unterschiede zu einem zentralisierten System:

Standardmäßig existiert keine kanonische Referenzkopie der Codebasis, sondern nur Arbeitskopien.
Gängige Operationen (wie Commits, Einsicht in die Historie und Rückgängigmachen von Änderungen) sind schnell, da keine Kommunikation mit einem zentralen Server erforderlich ist.

Vielmehr ist eine Kommunikation nur dann erforderlich, wenn Änderungen an andere Peers übertragen oder von ihnen zurückgezogen werden.

Jede Arbeitskopie fungiert als Remote-Backup der Codebasis und des Änderungsverlaufs und bietet somit einen inhärenten Schutz vor Datenverlust. ⓘ

Integration

Einige der fortschrittlicheren Werkzeuge für die Revisionskontrolle bieten viele weitere Funktionen, die eine tiefere Integration mit anderen Werkzeugen und Softwareentwicklungsprozessen ermöglichen. Häufig sind Plugins für IDEs wie Oracle JDeveloper, IntelliJ IDEA, Eclipse, Visual Studio, Delphi, NetBeans IDE, Xcode und GNU Emacs (über vc.el) verfügbar. Fortgeschrittene Forschungsprototypen generieren entsprechende Commit-Nachrichten, aber das funktioniert nur bei Projekten, die bereits eine große Historie haben, weil Commit-Nachrichten sehr von den Konventionen und Eigenheiten des Projekts abhängen. ⓘ

Gemeinsame Terminologie

Die Terminologie kann von System zu System variieren, aber einige Begriffe sind allgemein gebräuchlich:

Baseline

Eine genehmigte Revision eines Dokuments oder einer Quelldatei, an der spätere Änderungen vorgenommen werden können. Siehe Baselines, Labels und Tags.

Verursacher

Eine Suche nach dem Autor und der Revision, die eine bestimmte Zeile zuletzt geändert hat.

Zweig

Eine Gruppe von Dateien unter Versionskontrolle kann zu einem bestimmten Zeitpunkt verzweigt oder gegabelt werden, so dass sich von diesem Zeitpunkt an zwei Kopien dieser Dateien unabhängig voneinander mit unterschiedlicher Geschwindigkeit oder auf unterschiedliche Weise entwickeln können.

Änderung

Eine Änderung (oder Diff oder Delta) stellt eine spezifische Modifikation an einem Dokument unter Versionskontrolle dar. Die Granularität der Änderung, die als Änderung gilt, variiert zwischen den Versionskontrollsystemen.

Änderungsliste

In vielen Versionskontrollsystemen mit atomaren Multi-Change-Commits bezeichnet eine Änderungsliste (oder CL), ein Änderungssatz, ein Update oder ein Patch die Menge der in einem einzigen Commit vorgenommenen Änderungen. Sie kann auch eine sequentielle Ansicht des Quellcodes darstellen, die die Untersuchung des Quellcodes ab einer bestimmten Änderungslisten-ID ermöglicht.

Auschecken

Auschecken (oder co) bedeutet, eine lokale Arbeitskopie des Projektarchivs zu erstellen. Ein Benutzer kann eine bestimmte Revision angeben oder die letzte erhalten. Der Begriff "Checkout" kann auch als Substantiv verwendet werden, um die Arbeitskopie zu beschreiben. Wenn eine Datei von einem gemeinsam genutzten Dateiserver ausgecheckt wurde, kann sie nicht von anderen Benutzern bearbeitet werden. Stellen Sie sich das wie ein Hotel vor: Wenn Sie auschecken, haben Sie keinen Zugang mehr zu den Annehmlichkeiten des Hotels.

Klonen

Klonen bedeutet, ein Repository zu erstellen, das die Revisionen eines anderen Repositorys enthält. Dies ist gleichbedeutend mit einem Push oder Pull in ein leeres (neu initialisiertes) Repository. Als Substantiv können zwei Repositorys als Klone bezeichnet werden, wenn sie synchron gehalten werden und die gleichen Revisionen enthalten.

Commit (Substantiv)

Ein "Commit" oder eine "Revision" (SVN) ist eine Änderung, die auf das Repository angewendet wird.

Übertragen (Verb)

Ein Commit (check in, ci oder, seltener, install, submit oder record) bedeutet, dass die in der Arbeitskopie vorgenommenen Änderungen in das Projektarchiv zurückgeschrieben oder zusammengeführt werden. Ein Commit enthält Metadaten, typischerweise die Autoreninformation und eine Commit-Nachricht, die die Änderung beschreibt.

Konflikt

Ein Konflikt tritt auf, wenn verschiedene Parteien Änderungen an demselben Dokument vornehmen und das System nicht in der Lage ist, die Änderungen miteinander abzugleichen. Ein Benutzer muss den Konflikt auflösen, indem er die Änderungen kombiniert oder eine Änderung zugunsten der anderen auswählt.

Delta-Kompression

Die meisten Revisionskontrollprogramme verwenden eine Deltakomprimierung, bei der nur die Unterschiede zwischen aufeinander folgenden Dateiversionen gespeichert werden. Dies ermöglicht eine effizientere Speicherung vieler verschiedener Versionen von Dateien.

Dynamischer Datenstrom

Ein Stream, in dem einige oder alle Dateiversionen Spiegelungen der Versionen des übergeordneten Streams sind.

Exportieren

Der Export ist der Vorgang, bei dem die Dateien aus dem Repository geholt werden. Es ähnelt dem Auschecken, mit dem Unterschied, dass es einen sauberen Verzeichnisbaum ohne die Metadaten der Versionskontrolle erzeugt, die in einer Arbeitskopie verwendet werden. Dies wird zum Beispiel häufig vor der Veröffentlichung des Inhalts verwendet.

Holen

Siehe Pull.

Vorwärtsintegration

Der Prozess des Zusammenführens von Änderungen, die im Hauptstamm gemacht wurden, in einen Entwicklungszweig (Feature oder Team).

Kopf

Manchmal auch Tip genannt, bezieht sich dies auf den letzten Commit, entweder zum Stamm oder zu einem Zweig. Der Stamm und jeder Zweig haben ihren eigenen Head, obwohl HEAD manchmal auch für den Stamm verwendet wird.

Importieren

Unter Importieren versteht man das erstmalige Kopieren eines lokalen Verzeichnisbaums (der noch keine Arbeitskopie ist) in das Projektarchiv.

Initialisieren

Anlegen eines neuen, leeren Projektarchivs.

Interleaved Deltas

Einige Revisionskontrollprogramme verwenden Interleaved Deltas, eine Methode, die es ermöglicht, die Historie von textbasierten Dateien effizienter zu speichern als mit Delta-Kompression.

Etikett

Siehe Tag.

Sperren

Wenn ein Entwickler eine Datei sperrt, kann kein anderer diese Datei aktualisieren, bis sie entsperrt wird. Das Sperren kann durch das Versionskontrollsystem oder durch informelle Kommunikation zwischen Entwicklern (auch bekannt als Social Locking) unterstützt werden.

Hauptlinie

Ähnlich wie trunk, aber es kann eine mainline für jeden Zweig geben.

Zusammenführen

Eine Zusammenführung oder Integration ist ein Vorgang, bei dem zwei Sätze von Änderungen auf eine Datei oder einen Satz von Dateien angewendet werden. Einige Beispielszenarien lauten wie folgt:

Ein Benutzer, der an einer Reihe von Dateien arbeitet, aktualisiert oder synchronisiert seine Arbeitskopie mit Änderungen, die von anderen Benutzern vorgenommen und in das Projektarchiv eingecheckt wurden.
Ein Benutzer versucht, Dateien einzuchecken, die von anderen aktualisiert wurden, seit die Dateien ausgecheckt wurden, und die Revisionskontrollsoftware führt die Dateien automatisch zusammen (in der Regel, nachdem sie den Benutzer gefragt hat, ob sie mit der automatischen Zusammenführung fortfahren soll, und in einigen Fällen tut sie das nur, wenn die Zusammenführung eindeutig und vernünftig gelöst werden kann).
Es wird ein Zweig erstellt, der Code in den Dateien wird unabhängig voneinander bearbeitet, und der aktualisierte Zweig wird später in einen einzigen, vereinheitlichten Stamm integriert.
Ein Satz von Dateien wird verzweigt, ein Problem, das vor der Verzweigung existierte, wird in einem Zweig behoben, und die Korrektur wird dann in den anderen Zweig zusammengeführt. (Diese Art der selektiven Zusammenführung wird manchmal als "Cherry Pick" bezeichnet, um sie von der vollständigen Zusammenführung im vorherigen Fall zu unterscheiden).

Heraufstufen: Der Vorgang des Kopierens von Dateiinhalten von einem weniger kontrollierten Ort an einen stärker kontrollierten Ort. Zum Beispiel aus dem Arbeitsbereich eines Benutzers in ein Repository oder aus einem Stream in seinen Parent.
Pull, Push: Kopieren von Revisionen aus einem Repository in ein anderes. Pull wird vom empfangenden Repository initiiert, während Push von der Quelle initiiert wird. Fetch wird manchmal als Synonym für Pull verwendet, oder um einen Pull gefolgt von einer Aktualisierung zu bezeichnen.
Pull-Anfrage: Ein Entwickler bittet andere, seine "gepushten" Änderungen zusammenzuführen.
Projektarchiv: Das Repository (oder "Repo") ist der Ort, an dem die aktuellen und historischen Daten von Dateien gespeichert werden, oft auf einem Server. Manchmal auch Depot genannt.
Auflösen: Das Eingreifen eines Benutzers, um einen Konflikt zwischen verschiedenen Änderungen am selben Dokument zu lösen.
Rückwärtsintegration: Der Prozess des Zusammenführens verschiedener Teamzweige in den Hauptstamm des Versionierungssystems.
Revision: Auch Version: Eine Version ist jede Änderung in der Form. In SVK ist eine Revision der Zustand des gesamten Baums im Repository zu einem bestimmten Zeitpunkt.
Freigabe: Der Akt, eine Datei oder einen Ordner in mehreren Zweigen gleichzeitig verfügbar zu machen. Wenn eine freigegebene Datei in einem Zweig geändert wird, wird sie auch in anderen Zweigen geändert.
Stream: Ein Container für verzweigte Dateien, der eine bekannte Beziehung zu anderen Containern dieser Art hat. Streams bilden eine Hierarchie; jeder Stream kann verschiedene Eigenschaften (wie Versionen, Namespace, Workflow-Regeln, Abonnenten usw.) von seinem übergeordneten Stream erben.
Tag: Ein Tag oder Label bezieht sich auf eine wichtige Momentaufnahme in der Zeit, die über viele Dateien hinweg konsistent ist. Diese Dateien können zu diesem Zeitpunkt alle mit einem benutzerfreundlichen, aussagekräftigen Namen oder einer Revisionsnummer versehen werden. Siehe Baselines, Labels und Tags.
Trunk: Die einzelne Entwicklungslinie, die keine Verzweigung ist (manchmal auch Baseline, Mainline oder Master genannt).
Aktualisierung: Ein Update (oder Sync, aber Sync kann auch eine Kombination aus Push und Pull bedeuten) führt Änderungen, die im Projektarchiv (z.B. von anderen Personen) vorgenommen wurden, in die lokale Arbeitskopie ein. Update ist auch der Begriff, der von einigen CM-Werkzeugen (CM+, PLS, SMS) für das Konzept des Änderungspakets verwendet wird (siehe Changelist). Synonym für Auschecken in Revisionskontrollsystemen, bei denen jedes Projektarchiv genau eine Arbeitskopie haben muss (üblich in verteilten Systemen).
Freischalten: Freigeben einer Sperre.
Arbeitskopie: Die Arbeitskopie ist die lokale Kopie von Dateien aus einem Projektarchiv zu einem bestimmten Zeitpunkt oder einer bestimmten Revision. Alle Arbeiten, die an den Dateien in einem Projektarchiv vorgenommen werden, werden zunächst an der Arbeitskopie durchgeführt, daher der Name. Vom Konzept her ist sie eine Sandbox. ⓘ

Hauptaufgaben

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. ⓘ

Terminologie

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. ⓘ

Funktionsweise

Zentrale Versionsverwaltung

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. ⓘ

Objekt-basierte Versionierung

Ü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. ⓘ

Beispiele

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

	Open-Source-Systeme	Proprietäre Systeme ⓘ
Zentrale Systeme	MediaWiki SCCS RCS CVS Subversion (SVN)	Alienbrain Perforce Team Foundation Server Visual SourceSafe ClearCase IBM Rational Synergy PTC Integrity SAP Design Time Repository (DTR) versiondog (für SPS, Roboter, Automatisierungsgeräte) Sourcegear Vault (ehem. Fortress)
Verteilte Systeme	Bazaar BitKeeper Darcs Fossil Git GNU arch Mercurial Monotone	Rational Team Concert