Der designierte CVS-Nachfolger Subversion ist mittlerweile ziemlich populär und hat viele Einschränkungen des «Vorgängers» behoben. Doch nach wie vor wird bei der Versionskontrolle die eine oder andere Funktion vermisst, insbesondere Fähigkeiten zur Replikation oder zur Verteilung der Repositories.
Für die Replikation oder die Verteilung der Repositories gibt es mehrere Gründe. Einer ist die Verbesserung der Verfügbarkeit. Denn fällt der Subversion-Server aus, kann nicht mehr weitergearbeitet werden. Repliziert man nun die Repositories, kann auf einer dieser Repliken gearbeitet werden, bis der Hauptserver wieder verfügbar ist. Ein anderer Grund ist die Verbesserung der Zugriffsgeschwindigkeit, wenn beispielsweise an zwei verschiedenen Orten entwickelt wird und diese nur durch eine schmalbandige Leitung miteinander verbunden sind. Dank Replikation müssen nur Änderungen an den Repositories übertragen werden –aufwendige Operationen wie Status- oder History-Abfragen können alleine auf Basis des lokalen Replikats erfolgen. Das gleiche gilt auch für Entwickler, die viel auf Achse sind und eine lokale Kopie der Versionskontrolle vorhalten wollen, die sie jedes Mal, wenn sie im Büro sind, wieder mit dem Hauptserver synchronisieren.
Da Subversion keine Replikationsfunktionen mitbringt, muss man selber tätig werden und auf Third Party Tools setzen, welche auf Basis der eingebauten Subversion-Tools wie svn log Replikationsfähigkeiten beisteuern.
Ein sehr interessantes Werkzeug dazu ist Tailor (progetti.arstecnica.it/tailor). Die in Python implementierte Software ist darauf spezialisiert, Changesets zwischen verschiedenen Versionskontrollsystemen zu migrieren. So wird nicht nur Subversion, sondern auch eine grosse Palette anderer Systeme unterstützt, unter anderem Darcs, Monotone, CVS und Bazaar-NG. Das bedeutet, man kann nicht nur eine Subversion-nach-Subversion-Replikation aufsetzen, sondern auch verschiedene Systeme mischen und zum Beispiel Darcs als Master und Subversion als Slave nutzen.
Tailor wird von einer zentralen Konfigurationsdatei gesteuert, die sowohl die Einrichtung von One-Way- als auch Two-Way-Replikation erlaubt, sofern die Unterstützung für das jeweilige Versionskontrollsystem vorhanden ist. Da Tailor die Command-Line-Clients der Versionskontrollen nutzt, kann es sowohl mit lokalen als auch mit entfernten Repositories arbeiten. Im Falle von Subversion wird mittels svn log die History ausgewertet und entsprechend der Resultate lokale Working Copies angelegt. Auf Basis der Working Copies werden dann die Änderungen –je nachdem –an das lokale oder entfernte Repository übermittelt.
Bedingt durch die Funktionsweise arbeitet Tailor leider nicht automatisch. Ein Abgleich mit dem Master muss entweder manuell oder «halbmanuell» durch einen Cronjob ausgelöst werden. Sollte dabei ein Konflikt auftreten, weil beispielsweise sowohl auf dem Master als auch auf dem Slave die gleiche Änderung durchgeführt wurde, schreitet Tailor ein und fordert den Anwender dazu auf, den Konflikt zu beheben.
Einen automatischen Weg geht dagegen SVNreplicate (open.datacore.ch/wikipage/SVNreplicate). SVNreplicate ist eine Suite mehrerer sogenannter Hook Scripts. Mit Hilfe eines Hook Script ist es möglich, an mehreren vordefinierten Punkten innerhalb des Commit-Prozesses von Subversion mit eigenen Scripten einzugreifen und bestimmte Aktionen auszuführen. So lassen sich zum Beispiel Scripts zur Überprüfung von Code einklinken, die dann je nach Resultat den Commit durchlassen oder abbrechen. SVNreplicate macht sich diese Funktionalität zunutze und klinkt sich in den Commit-Prozess ein, um die Changesets abzugreifen und diese an die Slaves weiterzureichen. Da SVNreplicate dazu auf dem entfernten Server schreiben muss, muss eine SSH-Verbindung zwischen beiden Rechnern etabliert werden, die jeweils von SVNreplicate initiiert wird.
Wenn man SVNreplicate auch auf dem Slave einrichtet, wird aus der One-Way- eine Two-Way-Verbindung, bei der auf dem Slave nicht nur gelesen, sondern auch geschrieben werden kann. Gesamthaft werden dabei maximal 1 Master und beliebig viele Slaves unterstützt –mit anderen Versionskontrollen kann SVNreplicate dagegen nicht umgehen.
Während sowohl Tailor als auch SVNreplicate –ohne wertend zu sein –Bastellösungen sind, bringt svk von Haus aus Unterstützung für Replikation mit. Svk ist im Gegensatz zu den beiden bereits vorgestellten Lösungen kein Zusatzwerkzeug, sondern ein eigenes Versionskontrollsystem, womit es etwas aus dem Rahmen fällt.
Svk (svk.elixus.org) ist ein Fork von Subversion. Die Entwickler haben es sich zum Ziel gesetzt, ein voll kompatibles System zu entwickeln, das die meisten Schwächen von Subversion ausräumt. So basiert es einerseits auf der sehr stabilen Subversion-Filesystem-Bibliothek, verzichtet dagegen aber unter anderem auf den Subversion-Code zur Verwaltung der Working Copies, der nicht als sonderlich robust gilt. Ein Grossteil von svk ist in Perl implementiert, auch wird auf die .svn-Verzeichnisse zur Speicherung von Metadaten in den Working Copies verzichtet.
Dank dieser Veränderungen ist svk nicht nur ressourcenschonender, sondern auch flinker als Subversion. Doch der Hauptunterschied zwischen Subversion und svk liegt in svks Fähigkeiten zur Einrichtung und Verwaltung verteilter Repositories. Die Entwickler von svk haben dabei auf die Konzepte von Bazaar-NG zurückgegriffen. Dies hatte nicht nur Einfluss auf die Benennung gewisser Objekte (so heissen beispielsweise Working Copies bei svk Depots), sondern auch auf die Bedienung der Software, die sich durch die zusätzlichen Funktionen teilweise stark von derjenigen von Subversion unterscheidet. Nichtsdestotrotz konnte die Kompatibilität nicht nur auf Serverebene erhalten werden, sondern, was vielleicht sogar wichtiger ist, auch auf Ebene der Clients. So lassen sich Depots auch mit bestehenden Subversion-Tools wie TortoiseSVN verwalten.
Neben Werkzeugen zur Verwaltung, Synchronisation und Spiegelung von Remote-Repositories bringt svk auch Tools zum Mergen von Projekten. Weiter ist es sogar in der Lage, mit CVS-, Perforce-, Arch- oder cvsbk-Servern umzugehen und deren Repositories zu übernehmen. Damit eifert svk auch etwas Tailor nach, auch wenn es noch nicht derart viele Systeme unterstützt.
Welchen Weg man geht und welches der vorgestellten Werkzeuge man einsetzt, hängt von der jeweiligen Aufgabenstellung ab. Tailor bietet sich vor allem dann an, wenn Entwickler eine lokale Kopie der Repositories auf ihrem Laptop haben wollen oder die Zusammenarbeit mit anderen Versionskontrollsystemen gefragt ist, ohne dass man viel Arbeit und einen grossen Migrationsaufwand in Kauf nehmen muss. Vor allem zum Vorhalten eines aktuellen Slave ist SVNreplicate geeignet, da es dafür sorgt, dass Changesets kontinuierlich und ohne Verzögerung vom Master an die Slaves weitergegeben werden. Da es von SSH und einer konstanten Verbindung zwischen Master und Slaves abhängt, eignet es sich dagegen nicht dazu, um lokale Repositories auf Entwicklermaschinen zu erzeugen. Svk ist die Luxus-Lösung, die mächtige Tools mitbringt, um viele verteilte Repositories, auch auf Basis von Fremdsoftware, zu verwalten. Allerdings erkauft man sich diese Vorteile mit einer komplexeren Handhabung, sodass sich die Einführung von Svk nur bei grossen Projekten mit sehr vielen Entwicklern oder verteilten Standorten wirklich lohnt.
