Bei der praktischen Arbeit mit CVS stieß man allerdings immer wieder auf Stolpersteine, die die Arbeit unnötig erschwerten. Langjährige CVS-Benutzer hatten sich womöglich schon dran gewöhnt, dass man eine Datei nicht mal eben verschieben oder umbenennen konnte, ohne beispielsweise durch Auschecken und Neueinchecken ihre komplette Historie zu verlieren. Dies war nur durch eigenhändige Änderungen an Dateien auf dem CVS-Server durch den Admin möglich - und kam somit fast einer Operation am offenen Herzen gleich. Aber derartige Probleme im praktischen Einsatz zu beseitigen war gar nicht so einfach, denn sie lagen tief im Konzept von CVS begründet.

Aus den Bedürfnissen vieler Projektmanager entstand so die Idee, ein neues Versions-Kontrollsystem zu schaffen, welches flexibel und sauber durchdacht statt historisch gewachsen sein sollte. Geboren war die Idee von Subversion, bei welchem besonders darauf geachtet wurde, die in der praktischen Verwendung von CVS auftretenden Designfehlern möglichst elegant zu lösen. Im Gegensatz zu anderen Open Source-Projekten standen für Subversion bereits von Anfang an auch einige bezahlte Vollzeitprogrammierer zur Verfügung, was auf die zügige Entwicklung des Grundgerüsts sowie auch die weitere Entwicklung große Auswirkungen hat. Entstanden ist ein Versions-Kontrollsystem mit modularem Aufbau aus einer Sammlung aufeinander abgestimmter C-Bibliotheken mit klar definierten Aufgaben und Schnittstellen. In diesem hierarchischen Konzept stellt jeder Layer seinem übergeordneten Layer ein klares Interface zur Verfügung und kapselt seine Funktionalität. Hierdurch ist es möglich, auch in der späteren Entwicklung noch zentrale Veränderungen und Erweiterungen am Gesamtsystem vorzunehmen - ein offenes Konzept.

Abb. 1: C++-Client, der das wxWindows-Framework für Plattform-Unabhängigkeit verwendet
Bei Subversion werden, im Gegensatz zu CVS, die Versionen von Dateien nicht einzeln verwaltet. Alle Änderungen an Dateien und Verzeichnissen werden als Ganzes in einer Baumstruktur abgebildet. Somit existiert bei Subversion das eingangs beschriebene Problem der Umbenennung oder Verschiebung einer Datei (CVS) im Subversion-Konzept nicht mehr. Auch ermöglicht die gemeinsame Verwaltung von Versionsinformationen Transaktionen, wie sie viele beispielsweise von Datenbanksystemen kennen werden. Dies werden wir weiter unten zusammen mit dem Subversion-Dateisystem genauer erläutern.

Ein weiterer wesentlicher Vorteil von Subversion gegenüber CVS ist außerdem die Möglichkeit zur Speicherung von binären Unterschieden zwischen Dateien. Aufgrund des textbasierenden RCS-Dateiformat von CVS führt die Speicherung von Binärdateien im Repository immer zu einer kompletten Ersetzung der bisherigen Datei. Hierbei war sowohl eine komplette Übertragung (Bandbreitenverbrauch) als auch die komplette Speicherung (Speicherplatzbedarf auf dem Server) notwendig. Besonders der Aspekt des Speicherbedarfs auf dem Server ist bei der Speicherung von (größeren) Dateien durchaus beachtlich. Allein die Speicherung einer 200-kByte-Datei nimmt nach 50 Versionsständen alleine bereits 10 MByte Speicherplatz in Anspruch - auch wenn sich vielleicht nur wenige Bytes in der Datei wirklich geändert haben. Aus diesem Grund verwendet Subversion den DeltaV-Algorithmus, welcher auch bei Binärdateien die Erfassung von Unterschieden zwischen zwei Dateiversionen ermöglicht. Auf diese Weise können auch beispielsweise Grafiken, Icons oder Soundfiles effizient im Versions-Kontrollsystem verwaltet werden.

Abb. 2: Python-Client - plattform-unabhängige Oberfläche mittels GTK-Toolkit
Genaugenommen ist Subversion eigentlich noch im Alpha-Stadium - und dies gibt das Subversion-Team auch ganz klar zu. Auf ihrer Webpage findet sich sogar eine Auflistung (subversion.tigris.org/inconveniences.html) der aktuell noch existenten Probleme, welche beim Einsatz von Subversion evtl. auftreten können. Das System hat sich jedoch bereits in vielen kleineren und größeren Open Source-Projekten als überaus stabil und fortschrittlich erwiesen. So vertrauen beispielsweise die Programmierer von Subversion seit 1 1/2 Jahren ihrem System sogar die Verwaltung seines eigenen Quellcodes an. Auch werden seit Juni Debians XFree86-Pakete per Subversion gepflegt, um so im Team eine bessere Zusammenarbeit an den Paketen zu ermöglichen.

Bis zur Version 1.0 hat sich das Subversion-Team vorgenommen, vorrangig die Basisfunktionalitäten von CVS inkl. einiger Verbesserungen zu implementieren. Erst im Anschluss sind Features wie symbolische Links und komplette Internationalisierung (I18N) geplant. Aber schon heute, wo die Versionsnummer bei Redaktionsschluss gerade mal v0.26 zeigt, ist Subversion bereits ein stabiles und ausgefeiltes System.

Subversion-Dateisystem
Zur Speicherung von Dateien und den zugehörigen Informationen setzt Subversion auf ein eigenes Dateisystem. Dies ist jedoch nicht auf Kernel-Ebene realisiert, wie beispielsweise das ext2-System in Linux, sondern als logisches Filesystem, welches sich auf das SVN Repository-System stützt. Das Repository selbst basiert auf einer Datenbank (derzeit Berkley DB) und besteht somit aus einzelnen .db-Files. Hierüber simultiert eine C-API ein versioned filesystem und kapselt somit den Zugriff auf die zu Grunde liegenden Datenbank-Files. Die Handhabung der API ist der eines herkömmlichen Dateisystems ähnlich. Zusätzlich werden jedoch alle Änderungen im Dateisystem protokolliert und es ist an jeder Stelle möglich, auf frühere Zustände zurückzugreifen.

Abb. 3: Hochladen neuer Dateiversionen ins Repository - Fortschrittsanzeige
Im Gegensatz zu CVS, welches den aktuellen Revisionsstand pro Datei einzeln verwaltet, bedient sich Subversion einer Baum-Struktur um Revisionen zu kennzeichnen. Jedes atomare commit erzeugt hierbei einen neuen Revisionszweig mit einer eindeutigen, globalen Revisionsnummer. Geänderte Dateien und Verzeichnisse werden hierbei neu gespeichert, die bisherigen Dateien werden als Deltas zum letzten Stand archiviert. Nicht geänderte Dateien und Verzeichnisse müssen dank eines Shared Storage-Mechanismus nicht erneut gespeichert werden. Wer in CVS schon mal versucht hat, mehrere geänderte Dateien auf einmal einzuspielen, und feststellen musste, dass diese mit Änderungen von anderen Mitarbeitern des Teams kollidierten, musste seine bisher ausgeführten Checkins aufwändig wieder rückgängig machen, um den CVS-Source-Code wieder zu bereinigen. Dank der Transaktionen bei Subversion werden entweder alle Dateien auf einmal ins Repository übernommen oder der Commit-Vorgang rückgängig gemacht, um die Konflikte zu beheben.

Durch den Einsatz einer Datenbank wie derzeit der Berkley DB ist es somit automatisch möglich, wertvolle Features von Subversion zu realisieren: Datenintegrität, atomare Schreibzugriffe, Recover-Möglichkeiten sowie Hot-Backups.

Netzwerk-Layer
Zur Realisierung einer Portabilität auf möglichst viele Plattformen bedient sich Subversion der Apache Portable Runtime Library (APR) und profitiert somit von einer ähnlichen breiten Plattformabdeckung wie der Apache-httpd. Darüber hinaus dient Apache aber auch als Netzwerkebene für Subversion. Die Entscheidung für Apache fiel, da es sich hierbei um ein stabiles und bewährtes System handelt, welches auch unter hoher Netzwerklast tadellos seinen Dienste zur Verfügung stellt. Außerdem stehen zahlreiche nützliche Module bereit, die unabhängig von Subversion weiterentwickelt und gepflegt werden. Somit profitiert Subversion durch ihre Verwendung direkt von der Arbeit anderer Projekte und kann sich selbst auf die elementaren Teile ihres eigenen Systems konzentrieren. Beispielsweise stützt sich Subversion für die Netzwerkkommunikation auf das mittlerweile bereits in vielen Produkten implementierte WebDAV-Protokoll, welches von seinem Design bereits für verteilte Datenablage per HTTP sowie damit zusammenhängend auch für Versionsverwaltung konzipiert ist (DAV = distributed authoring and versioning). Aber auch weitere Basisfunktionalitäten wie Authentifizierung per htpasswd, verschlüsselte Datenübertragung per mod_ssl oder die Kompression der übertragenen Daten mittels mod_deflate machen Apache zu einer sehr guten Wahl und lassen sich problemlos mit dem WebDAV-Protkoll verbinden. Der Einsatz von Apache erlaubt darüber hinaus, auch das Repository-Verzeichnis gleichzeitig per HTTP zugänglich zu machen, um somit ohne den Einsatz eines Subversion Clients schnell und unkompliziert auf einzelne Dateien zugreifen zu können.

Abb. 4: Kontextmenü-Erweiterung eines Verzeichnis - so nahtlos integriert sich TortoiseSVN
Benutzer, welche lokal auf ein Subversion Repository zugreifen, brauchen selbstverständlich nicht den umständlichen Weg über WebDAV wählen. Hierzu existiert eine Library, welche einen direkten, lokalen Zugriff auf das Subversion Repository ermöglicht. Um einen einheitlichen Repository-Zugriff zu ermöglichen, wurde eine abstrakte API gewählt, durch welche der Zugriff sowohl für lokale als auch auf entfernte Repositories möglich ist. Auch können Entwickler mittels durch Implementierung der abstrakten Schnittstelle bei Bedarf eigene Repository-Zugriffsmöglichkeiten über andere Protokolle schaffen.

Client Library
Ein wichtiger Teil der Arbeit von Subversion wurde in der Client Library implementiert. Sie dient beispielsweise dazu einen Baum aus einem entfernten Repository mittels Netzwerk-Layers anzufordern und ist für die lokale Ablage einer Arbeitskopie dieses Baumes verantwortlich. Hierbei ist auffällig, dass im Verzeichnis SVN/ alle wichtigen Informationen gespeichert werden. Die Datei entries beispielsweise enthält XML-Daten, welche den aktuellen Stand der lokalen Arbeitskopie des Repositorys enthalten. Sie bildet somit im Vergleich zu CVS eine Kombination aus den CVS-Dateien für entries, root und repository. Weitere Dateien unterhalb SVN/ dienen außerdem beispielsweise zur Ablage von Meta-Daten (der so genannten properties) zu den einzelnen Verzeichnissen und Dateien im Repository. Durch die Speicherung von Versionsinformationen der ursprünglichen Dateien der Arbeitskopie des Repositorys ist es auch ohne Netzwerkzugriff möglich, sowohl Veränderungen an lokalen Dateien festzustellen als auch neue Revisionen anzulegen. Um im Falle einer Synchronisation der Repository-Daten mit dem Server eine möglichst geringen Bandbreiten-Nutzung zu erreichen, hat sich das Subversion-Projekt für eine lokale Repository-Kopie entschieden. Zwar wird bei dieser Methode zusätzlicher Speicherplatz auf dem Client belegt, sie ermöglicht es jedoch bei der Synchronisation in beiden Richtungen lediglich diffs zu übertragen, was vielfach mit einer erheblichen Traffic- und letztendlich auch Zeitersparnis verbunden ist.

Durch seine Aufgabe zur Verknüpfung der lokalen Arbeitskopie des Repositorys sowie dem Library für den Remote Access (RA) auf ein entferntes Repository bildet sie einen zentralen Bestandteil des Subversion-Konzepts. Sie ist beispielsweise auch für die Überprüfung auf Änderungen zwischen lokalen und entfernten Versionen zuständig als auch für die Übertragung der Änderungen ins Repository sowie zur Konfliktbearbeitung.

Abb. 5: Verwalten verschiedener Versionsstände
Diese äußerst wichtige Library wurde konzipiert um Applikationen zentral die Arbeit der Versionsverwaltung abzunehmen. Sie kann von jeglichen Applikationen verwendet werden, welche dann ihrerseits sowohl kommandozeilenbasierende wie auch grafische Oberflächen zur Verfügung stellen. Durch die Verwendung von SWIG-Schnittstellen (www.swig.org/) ermöglicht die Client Library eine nahezu problemlose Integration in viele Hochsprachen. SWIG ermöglicht hierbei vorrangig die Integration in Skriptsprachen wie Perl, Python, Tcl/Tk oder Ruby, aber auch zu Nicht-Skriptsprachen wie Java oder C#. Zum Zugriff auf einen Subversion-Server existieren unter anderem die grafischen Oberflächen RapidSVN (wxWindows-basierend und somit cross-plattform-portabel) und gSVN (Python-GUI per GTK).

Abb. 6: Subversion-Properties einer Datei einsehen/ändern
Des Weiteren ermöglichen Plugins die Integration von Subversion-Client-Funktionalitäten an verschiedenen Stellen. TortoiseSVN wählt hierzu den Weg der Integration in den Windows Explorer, Subclipse ist ein passendes Plugin für die Eclipse-Entwicklungsumgebung und SubWiki ist eine Wiki-Umsetzung mittels Zugriff auf Subversion.

Fazit
Insider prophezeien mittlerweile, dass Subversion innerhalb von drei Jahren möglicherweise das Standard-SCM-System der Open Source-Community werden könnte. Aufgrund seiner überlegenen Architektur, Portabilität und schon jetzt weit reichenden Plugins für viele Betriebssysteme, Editoren und Entwicklungsumgebungen stehen die Chancen auf jeden Fall ziemlich gut.
Stefan Neufeind ist Informatik-Student und beschäftigt sich seit mehreren Jahren intensiv mit Open Source/Linux/PHP. Neben seinem Studium ist er als freier Mitarbeiter für die Internet-Agentur SpeedPartner tätig. Kontakt: neufeind@speedpartner.de.