Subversion

Dieser Artikel wird derzeit von einem Autor gründlich bearbeitet. Die Inhalte sind daher evtl. noch inkonsistent.

Definition

Eine Versionsverwaltung hat die Aufgabe, den Werdegang eines Projektes zu protokollieren. Sie übernimmt die Versionierung und die Archivierung der Daten und ermöglicht den gemeinsamen Zugriff darauf. Dabei kann jede Änderung und jeder Stand verfolgt, rückgängig gemacht oder wiederhergestellt werden.

Subversion

Bis zum Jahr 2000 entwickelte sich CVS zum de-facto-Standard in der Open-Source-Gemeinde. Allerdings tauchten zunehmend Bugs und umständliches und fehlerhaftes Verhalten von CVS auf, was Anfang 2000 CollabNet Inc. dazu veranlaßte, Entwickler für eine Ablösung von CVS zu suchen. Ziel war es, eine komplett neue Versionsverwaltung, auf einigen guten Ideen von CVS aufbauend, zu entwickeln – allerdings ohne dessen Fehler und zusätzlich den Anforderungen der modernen Softwareentwicklung angepaßt. Im Februar 2000 begannen dann Karl Fogel und sein Freund Jim Blandy mit der Entwicklung von Subversion.

Hauptvorteile

Die Hauptvorteile – als Verbesserung zu CVS – sind nach dem offiziellen Handbuch:

• Verzeichnisversionierung: Nicht nur einzelne Dateien, sondern der komplette Verzeichnisbaum wird mitversioniert.
• Echte Versionsgeschichte: Dateien und Verzeichnisse können nun auch kopiert und umbenannt werden, ohne deren Historie zu verlieren.
• Atomare Commits: Ein Befehl wird nun entweder komplett oder gar nicht ausgeführt. So ist es unmöglich, daß nach einem Fehler in einer Datei alle bisherigen Veränderungen erhalten bleiben.
• Versionierte Metadaten: Jede Datei oder jedes Verzeichnis kann beliebige, zusätzliche Informationen – in Form von Schlüssel- und Wertepaaren – enthalten. Diese Informationen werden mitversioniert.
• Auswahl der Netzwerkschicht: Subversion kommt entweder als Apache-Erweiterung oder als leichtgewichtiger Standalone-Server.
• Konsistentes Datenmanagement: Nun können nicht nur aus Textdateien sondern auch aus Binärdaten Diffs erzeugt werden.
• Effizientes Branching und Tagging: Der Aufwand steigt nun nicht mehr proportional zur Projektgröße an sondern ist immer gleich effizient.
• API: Subversion kommt als eine Sammlung gemeinsamer C-Bibliotheken mit einer gut definierten API, auf die auch von externen Anwendungen zugegriffen werden kann.

Ein weiterer großer Vorteil, der zu dem großen Erfolg von Subversion geführt hat, ist die einfache Konvertierung eines alten CVS-Repositories in ein Subversion-Repository ohne Informationsverlust mit nur einem Befehl: cvs2svn (CVS to Subversion Repository Converter).

Server Einrichten

Das Repository, auch Archiv genannt, ist eine zentrale Referenzkopie aller Daten des Projektes inklusive der gesamten Versionsgeschichte, also aller alten Stände. Dieser Datenbestand wird auf dem Subversion-Server gespeichert und verwaltet.

Um ein neues SVN-Repository anzulegen, ist folgender Aufruf nötig:

svnadmin create <repository>

Für <repository> wird das anzulegende Unterverzeichnis, also der Repository-Name, angegeben. Als optionaler Parameter kann übergeben werden, welcher Datenbank-Typ das Repository verwenden soll. Standardmäßig wird fsfs ausgewählt. Folgende zwei Möglichkeiten stehen zur Auswahl, wobei jede ihre Vor- und Nachteile hat. Die genauen Unterschiede werden in beschrieben. Im allgemeinen wird aber eher zu fsfs geraten:

• Berkeley DB: Dieses Repository baut auf der Berkeley Datenbank auf und ist seit 2001 im Einsatz. Das System ist sehr anfällig gegenüber Unterbrechungen und wird dann schnell instabil, auch belegt das Repository etwas mehr Speicher als mit fsfs. Dafür skaliert die Datenbank besser, wenn extrem viele Revisions-Bäume existieren. Sie ist ebenfalls etwas schneller, wenn nur die aktuelle Revision ausgecheckt werden soll. Bei vielen Dateien pro Revision ist sie jedoch wieder langsamer und hat Probleme, wenn verschiedene Benutzergruppen darauf zugreifen. Vorteil wiederum ist, daß vom kompletten System während der Laufzeit ein Backup gemacht werden kann.

• fsfs baut auf gar keiner Datenbank, sondern nur auf dem Dateisystem, auf. Es ist ziemlich unempfindlich gegenüber Unterbrechungen und kann auch von Read-Only-Laufwerken und über Netzwerke gemounted werden. Das Repository ist etwas kleiner, hat aber bei veralteten Dateisystemen Skalierungsprobleme, wenn mehrere tausend Dateien in einem Verzeichnis existieren. Beim Einchecken großer Daten ist es etwas schneller, bei der aktuellen Revision dafür einen Moment langsamer. fsfs wird seit 2004 eingesetzt und die Programmierer empfehlen – außer es sprechen gute Gründe dagegen – alte Berkeley-DBs auf das fsfs-System umzuwandeln.

Um das nun erstellte Repository online zu stellen und den SVN-Server zu starten, existieren prinzipiell zwei Möglichkeiten: Als Apache-Plugin oder als Standalone-Server. Hier soll der einfachere Weg über den Server erklärt werden:

Zuerst muß noch festgelegt werden, wer welchen Zugriff und welche Rechte besitzt. Dies geschieht in den Dateien conf/svnserv.conf, conf/authz und conf/passwd.

Um den Server nun zu starten, ist aus dem SVN-Root Verzeichnis, welches die einzelnen Repositories enthält, folgendes Kommando notwendig:

svnserve –d –r .

Der Parameter d bewirkt, daß der Dienst als Deamon gestartet wird und r gibt das SVN-Root-Verzeichnis an – im obigen Fall also das aktuelle, da wir uns schon im richtigen Verzeichnis befinden.

Client-Zugriff

Am einfachsten und schnellsten ist der Einsatz der Kommandozeile. Mit dem vorherigen Paket wurden auch gleich alle benötigten Teile des Clients mitinstalliert. Alle Aufrufe finden über das Programm svn statt. Eine komplette Beschreibung der möglichen Kommandos befindet sich im offiziellen Handbuch.

Der Workspace ist die aktuell von einem Benutzer bearbeitete Version der Referenzkopie. Es können zu jedem Zeitpunkt beliebig viele, voneinander unabhängige Workspaces von verschiedenen Benutzern gleichzeitig bearbeitet werden.

Ein Checkout ist das initiale Erstellen eines lokalen Workspaces als eine Kopie des aktuellen Stands des Repositories oder einer beliebigen, älteren Version davon:

svn co svn://<server>/<repository>

Die Rückmeldung von Subversion ist der jeweils gerade ausgecheckte Revisionsstand.

Um beliebige Dateien oder komplette Verzeichnisse aus dem lokalen Workspace zu dem Repository hinzuzufügen, benötigt man folgenden Befehl:

svn add <Datei-/Pfadname> …

Der Unterschied zwischen zwei Versionen einer Datei ist nun ein Diff. Es enthält die nötigen Änderungsanweisungen, eine Datei von einem älteren Stand i auf den neueren Stand i+1 zu bringen. Wenn eine Datei im Repository aktualisiert wird, speichert Subversion nicht jedes Mal den kompletten Inhalt der Datei ab, sondern nur die Veränderungen zur jeweils älteren Version. Somit wird nicht nur Speicherplatz gespart, sondern auch die Darstellung der Änderungen erleichtert. Um stets eine gute Performance liefern zu können, liegt nicht die erste, ursprüngliche Version, sondern die jeweils aktuellste der Datei als komplette Datei vor. Gespeichert selbst werden nur die Änderungen zur Vorgängerversion. Ein Patch ist die Einarbeitung dieser Unterschiede in eine Datei mit altem Stand. Nach dem Patch ist diese auf dem neuen Stand.

Ein Commit (Check-In) ist ein Diff des lokalen Workspaces gegen das Repository, das anschließend in das Repository gepatched wird; also das Einarbeiten der durchgeführten Änderungen im Workspace in das Repository.

Ein Commit wird immer dann durchgeführt, wenn eine Änderung in der lokalen Kopie vorgenommen wurde und veröffentlicht werden soll. Um die eben neu hinzugefügten Dateien aus dem lokalen Workspace in das Repository zu übertragen, müssen diese eingecheckt werden:

svn ci -m "<Log-Message>"

Zusätzlich gibt man hierbei eine Log-Message ein, damit für jeden ersichtlich wird, was bei dieser Änderung geschehen ist. Als Rückmeldung gibt Subversion zu jeder neuen bzw. veränderten Datei die durchgeführten Aktionen und zum Schluß die neue Revision des Repositories.

Ein Update aktualisiert den lokalen Workspace anhand der neuesten Version im Repository. Damit erhält der Benutzer den derzeit aktuellsten Stand mit allen Änderungen, die zu diesem Zeitpunk bestätigt wurden. Sollten gleichzeitig an derselben Datei von verschiedenen Benutzern, also in verschiedenen Workspaces, Änderungen durchgeführt worden sein, so kann der erste seine Änderung noch ungehindert einchecken. Der Zweite muß seinen lokalen Workspace allerdings zuerst aktualisieren (Update), bevor er seine Änderungen senden kann, da er diese Änderungen der Datei auf einen mittlerweile veralteten Stand aufgebaut hat. Dabei werden die beiden Dateien automatisch gemerged. Ein Merge führt somit verschiedene Änderungen aus zwei Dateien zu einer zusammen. Dies geht jedoch nur gut, solange die Änderungen an verschiedenen Stellen der Datei vorgenommen wurden. Betreffen die Veränderungen allerdings die gleichen Zeilen oder mittlerweile sogar gelöschte Zeilen, so tritt ein Merge-Konflikt auf, der nicht automatisch gelöst werden kann. Somit muß der zweite Benutzer beide Veränderungen analysieren und gegebenenfalls anpassen, bevor er diese endgültig eincheckt.

Bevor man selbst Änderungen am lokalen Workspace durchführt, sollte man also seine Kopie mit einem Update auf den aktuellsten Stand bringen:

svn up

Subversion gibt nun Informationen zu den eben veränderten Dateien zurück. Die Möglichkeiten sind: Neu hinzugefügt, gelöscht, aktualisiert, vermischt (merge) und Konflikt. Dabei sind die letzten beiden Möglichkeiten besonders zu beachten: Bei einem Merge sollte sich der Entwickler das Ergebnis ansehen und bei einem Konflikt muß er diesen manuell beseitigen und anschließend die korrigierte Version wieder einzuchecken.

Der Update-Befehl muß aber nicht zwangsläufig immer die aktuellste Version auschecken, sondern kann mit dem Parameter r auch eine beliebige, alte Revision laden.

Geschichte

SCCS

Das Source Code Control System (SCCS) war eine der ersten Versionsverwaltungen. Es wurde Anfang der Siebziger von Marc Rochkind bei AT&T entwickelt. Dieses System konnte schon mehrere Versionen einer Datei verwalten. Da es aber in jeder Hinsicht modernen Systemen unterlegen ist, existieren heutzutage praktisch keine Projekte mehr damit.

RCS

Das Revision Control System (RCS) war die erste große Versionsverwaltung im Open-Source-Bereich. Es wurde 1985 von Walter Tichy an der Purdue University entwickelt. Dabei kam zum ersten Mal eine Technik mit dem Namen Lock-Modify-Unlock-Mechanismus zum Einsatz. Damit können mehrere Benutzer auf eine gemeinsame Datei lesend zugreifen. Soll eine Änderung vorgenommen werden, muß die entsprechende Datei zuerst gesperrt werden. Danach kann kein anderer Benutzer die Datei mehr bearbeiten, bis diese wieder freigegeben wird. So wird zu jeder Zeit sichergestellt, daß nicht mehrere Benutzer gleichzeitig eine Datei verändern.

CVS

Die Weiterentwicklung von RCS ist das Concurrent Versions System (CVS). In den Anfängen, noch von Dick Grune in Shell-Skripten implementiert, wurde es dann 1989 von Jeff Polk und Brian Berliner in C komplett neu implementiert. Die größten Neuerungen waren sicherlich die eingeführte Client-Server-Architektur und der implementierte Copy-Modify-Merge-Mechanismus. Im Gegensatz zu RCS wird nichts gesperrt, sondern der aktuelle Stand vor einer Änderung in einen lokalen Workspace kopiert, indem dann auch die Änderungen stattfinden. Bei der abschließenden Veröffentlichung der Daten werden die Änderungen mit dem zentralen Repository wieder abgeglichen. Dadurch war es zum ersten Mal möglich, daß viele Benutzer gleichzeitig am selben Projekt, ja sogar in denselben Dateien, arbeiten konnten. Unterstützend kam noch hinzu, daß nicht, wie bisher, jede Datei komplett unabhängig von den anderen betrachtet wurde, sondern, daß nun Gruppen von Dateien zu Modulen zusammengefaßt werden konnten.

Quellen

• Don Bolinger, Tan Bronson, Applying RCS and SCCS, O'REILLY, 1. September 1995, ISBN 1565921178
• Gregor N. Purdy, CVS kurz & gut, O’Reilly Verlag, Köln, 1., korrigierter Nachdruck Dezember 2001, ISBN 3-89721-229-3
• Derek Robert Price & Ximbiot, CVS - Concurrent Versions System, CVS-Homepage
• Karl Fogel, Moshe Bar, Open Source-Projekte mit CVS, Verteilte Softwareentwicklung mit dem Concurrent Versions System, mitp-Verlag, Bonn, 2., erweiterte und überarbeitete Auflage 2002, ISBN 3-8266-0816-x
• Ben Collins-Sussman, Brian W. Fitzpatrick, C. Michael Pilato, Version Control with Subversion, For Subversion 1.1, book compiled from Revision 1337, 2005, http://svnbook.red-bean.com/
• CollabNet, Inc., Subversion Homepage, Subversion-Homepage

• Vergleich von 13 Versionsverwaltungen (en.)