Mancher Softwareentwickler wird das Szenario kennen: Hier eine Änderung, dort noch zwei, am anderen Ende noch eine Funktion löschen und – die Software funktioniert nicht mehr, und wo man was geändert hat, ist spätestens am nächsten Morgen vergessen. Damit sich diese Probleme nicht häufen und man nicht wertvolle Zeit damit verschwenden muss, die Fehler zu lokalisieren und Änderungen zu verfolgen kann, bietet sich der Einsatz eines Source-Code-Managers – kurz SCM – an, der spätestens bei der Arbeit in Teams unverzichtbar wird.
Der wohl populärste SCM ist CVS, das Concurrent Versions System, das von vielen Open-Source-Projekten zur Versionskontrolle eingesetzt wird, doch haften dem System architekturbedingt eine Reihe von Problemen an.
CVS war ursprünglich eine Sammlung von Shellscripts, die das Bedienen des Revision Control Systems (RCS) vereinfachen und erweitern sollten. Auch wenn CVS mittlerweile komplett in C geschrieben wurde, basiert es nach wie vor auf dem RCS-Dateiformat und ermöglicht darum nur die Versionierung von Textdateien. Was für Sourcecode kein Problem ist, wird spätestens dann mühsam, wenn man Dokumente aus einer Textverarbeitung, PDFs oder Bilddateien versionieren will, die zum Projekt gehören. CVS muss für die Annahme von Binärdaten speziell vorbereitet werden und fügt bei jeder Revision die komplette Datei neu ein. Hat man also beispielsweise einen Splashscreen mit einer Grösse von 500 kB im Repository, wächst dieses bei jeder Revision um 500 kB. Auch in Zeiten von billigen Festplatten ein Ärgernis.
Dies ist aber nicht die einzige Schwäche, welche die dateibezogene Versionierung mit sich bringt. Löscht man eine Datei oder ein Verzeichnis, lässt sich dies später nicht mehr nachvollziehen, genauso wenig, wie wenn eine Datei umbenannt wird. Dies ist nur möglich, indem man die Datei unter dem alten Namen zuerst löscht und dann unter dem neuen Namen wieder hinzufügt. Für CVS ist die Datei dann aber neu und somit wird die History nicht übernommen. Zwar kann mit Hilfe einiger Tricks wie der Vergabe von Labels etwas nachgeholfen werden, allerdings ist dies keine wirkliche Lösungen.
Das freie Subversion wurde von Anfang an als ‘CVS ohne Designfehler’ konzipiert. Dabei ging es darum, das Verhalten von CVS grundsätzlich 1:1 nachzubilden und gleichzeitig die Schwächen auszubügeln. Entsprechend ähnlich ist das System in der Bedienung. Die Befehle (checkout, commit, add, update) heissen grösstenteils gleich, und man arbeitet auch mit einer sogenannten Working Copy. Das bedeutet, dass man sich vor Arbeitsbeginn die aktuellste Version vom Server auf die lokale Festplatte holt und dann mit diesen Dateien arbeitet. Somit lässt sich der Datentransfer klein halten, und die
Dateien werden bei einer Bearbeitung nicht gelockt. Dies kann sehr praktisch sein, wenn grosse Teams an einer Software arbeiten.
Während CVS, wie bereits erwähnt, auf Textdateien zur Datenspeicherungen setzt, verwendet Subversion Sleepycats Berkeley DB. Diese ermöglicht eine flexible Speicherung der Daten, auch wenn sie binär sind. Das Vergleichen verschiedener Revisionen (diff) geschieht mit Hilfe eines Algorithmus namens Vdelta, der nicht nur ein sehr effizientes Vergleichen reiner Text-, sondern auch von Binärdaten ermöglicht. Damit lassen sich nun auch PDF-Dateien oder Bilder versionieren.
Wie bereits erwähnt, lässt sich nun auch das Löschen oder Umbenennen von Dateien oder ganzen Verzeichnissen nachvollziehen, wozu Subversion den Befehl move kennt.
Ebenfalls ein grosser Fortschritt sind die atomaren Commits. Schlägt irgendein Schritt des Commits fehl, beispielsweise, weil ein Versionskonflikt entstanden ist, akzeptiert CVS die bereits gesendeten Dateien und verwirft den Rest. Während man den Versionskonflikt behebt, befinden sich die versionierten Daten nicht im gewünschten Zustand, was beispielsweise zum Nichtfunktionieren der Software führen kann. Subversion reagiert in diesem Fall anders und akzeptiert den gesamten Commit nur, wenn garantiert jede Datei angenommen kann.
Besonders viel Bauchschmerzen bereiten Administratoren meist die schlechte Netzwerkperformance von CVS und die einhergehenden
Sicherheitsprobleme. So werden bei CVS’ pserver, der eigentlich für den Netzwerkverkehr gedacht ist, Passwörter und alle anderen Daten im Klartext verschickt. Dies ist, besonders bei der Verwendung über das Internet, unerwünscht. Einzige Möglichkeit, um die Übertragung zu verschlüsseln, ist die Verwendung eines SSH-Tunnels, der aber einen Shell-Account auf dem CVS-Server voraussetzt – ebenfalls schlecht.
Subversion setzt auf der Serverseite nicht auf eine Eigenentwicklung, sondern auf den Apache-Webserver und die Apache-Module mod_dav und mod_dav_svn. Als Kommunikationsprotokoll wird WebDAV über HTTP oder HTTPS verwendet, womit sich mit Hilfe von SSL der komplette Datentransfer verschlüsseln lässt. Auch die Benutzerauthentifizierung wurde massiv vereinfacht: Es werden Apache htpasswd- und Groupfiles verwendet, womit sich der Zugriff einfach regulieren und verwalten lässt. Die Zugriffsrechte der Benutzer lassen sich auf eines oder mehrere Repositories begrenzen. Auch kann bestimmt werden, ob sie nur lesend oder auch schreibend zugreifen dürfen. Unix-Accounts sind nicht nötig.
Die Verwendung von WebDAV ermöglicht den Zugriff mit verschiedenen Clients, auch lassen sich die Subversion-Repositories bei Betriebssystemen wie Windows oder Mac OS X direkt in die Dateibrowser integrieren.
Da Subversion als Nachfolger von CVS konzipiert wurde, hat man auch darauf geachtet, bestehende CVS-Installationen übernehmen zu können. Entsprechend wurden passende Utilities entwickelt, welche die Konvertierung von bestehenden CVS-Repositories ermöglichen, und auch die Befehle zur Bedienung möglichst ähnlich gehalten.
Für Entwickler, die weniger ein Fan der Kommandozeile sind, sind verschiedene Clients (RapidSVN, TortoiseSVN) verfügbar, die ebenfalls im Vergleich zu ihren CVS-Pendants eher zu überzeugen wissen, da sie nicht über das CLI übergestülpt werden, sondern direkt auf die Subversion-Client-Libraries zurückgreifen. Dies sorgt für einen weitaus professionelleren und reibungslosen Betrieb, womit Subversion auch tauglicher für Unternehmen sein dürfte als sein Vorgänger.
Die Installation ist auch mit weniger Erfahrung in der Administration von unixoiden Systemen machbar. So bieten die meisten grossen Linux-Distributoren vorkompilierte Pakete und How-tos an, mit denen sich ein Subversion-Server innerhalb einer halben bis einer Stunde in Betrieb nehmen lässt. In der Administration ist Subversion eher unkritisch, vor allem, wenn man sich bereits mit dem Apache Webserver gut auskennt. Die Stabilität weiss ebenfalls zu überzeugen, was die Erfahrungen der Subversion-Entwickler noch weiter bestärken: Subversion verwaltet sich schon seit langer Zeit selber, und bisher ist es noch zu keinem Datenverlust gekommen, obwohl man die erste richtig stabile Version 1.0 erst im Februar erreicht hat.
