Ein gut strukturiertes Konzept findet sich bei der Versions-Kontrolle mit Subversion

Vielseitig erweiterbar
Kommentare

In den letzten Jahren hat sich CVS aufgrund eines weit verbreiteten Einsatzes zu einem De-facto-Standard unter den Sourcecode-Managern (SCM) entwickelt. Durch die Verwendung von CVS wurde die gemeinsame Arbeit an Dateien und insbesondere Sourcecode wesentlich erleichtert bzw. die effektive Verwaltung von unterschiedlichen Versionsständen überhaupt erst ermöglicht. Ohne die ausgiebige Verwendung von CVS zur Schaffung einer gemeinsamen Arbeitsplattform hätten Communities wie Freshmeat oder Sourceforge mit Sicherheit niemals ihren heutigen Status erreicht.

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

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.

Abb. 4: Kontextmenü-Erweiterung eines Verzeichnis – so nahtlos integriert sich TortoiseSVN

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 pictureet 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 pictureet 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. 6: Subversion-Properties einer Datei einsehen/ändern

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.

Befehl Aktion
co/checkout lokale Arbeitskopie einer Datei aus dem Repository anlegen
ci/commit lokale Arbeitskopie ins Repository einfügen
up/update aktualisieren der lokalen Arbeitskopie auf den letzten Stand des Repository
status Anzeige aller lokalen Änderungen; Änderungen werden jedoch nicht dem Repository hinzugefügt
add,rm/remove Dateien dem Repository hinzufügen bzw. aus dem Repository entfernen
cp/copy, mv/move kopiert bzw. verschiebt Datei oder Verzeichnis im Repository; bisherige History wird beibehalten
merge fügt Änderungen aus dem Repository in die lokale Arbeitskopie ein
diff Unterschiede zwischen lokaler Arbeitskopie und aktueller Version im Repository anzeigen
propadd, propdel, proplist, propview beliebige Metadaten zu einer Datei/einem Verzeichnis ändern/anzeigen; es existieren spezielle Metadaten-Schlüssel mit besonderen Bedeutungen

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.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -