Apache Subversion
Subversion (SVN) ist eine Open-Source-Software zur Versionsverwaltung. Da es viele Schwächen des in Entwicklerkreisen sehr beliebten Programms CVS behebt, wird Subversion oft als dessen Nachfolger bezeichnet, obwohl es sich um ein eigenständiges Projekt handelt. Es ist jedoch absichtlich von der Bedienung sehr ähnlich gehalten. CVS-Umsteiger werden es deshalb zu schätzen wissen, dass man bei den meisten Befehlen lediglich das cvs durch svn ersetzen muss. Zusätzlich zu vielen neuen Features, werden fast alle Funktionen von CVS unterstützt. Mit cvs2svn existiert ein Konverter, mit dem ein CVS-Repository zu Subversion konvertiert werden kann.
Subversion wird seit Anfang 2000 bei CollabNet entwickelt und erreichte im Februar 2004 die stabile Version 1.0. Ende September 2004 erschien Version 1.1, die Repositories nicht nur in einer Berkeley-Datenbank verwalten, sondern dazu auch ein Dateisystem benutzen kann (siehe unten). Seit Version 1.2 (Mai 2005) unterstützt Subversion außerdem optionales file-locking, was für binäre Dateien von Vorteil sein kann.
Vorteile gegenüber CVS
- In Subversion können Dateien (und Verzeichnisse) auch umbenannt und verschoben werden. In CVS muss eine Datei an der alten Stelle auf "Gelöscht" gesetzt und an der neuen Stelle neu eingefügt werden, wobei die Historie der Datei nicht übernommen wird.
- Subversion kann auch Verzeichnisse und Dateiberechtigungen (rwx) verwalten.
- Subversion bietet einen verbesserten Umgang mit Binärdaten. Es erkennt binäre Dateien (beispielsweise Bilder oder Audiodateien) automatisch und es werden (wie bei Textdateien) nur die Differenzen zwischen den geänderten Versionen gespeichert. In CVS geht das umständlicher über Eintrag von binären Dateitypen (deren Endung) in cvswrappers und wobei diese Filetypen voll gespeichert werden.
- Commits sind in Subversion atomar, weshalb eine Änderung entweder komplett oder gar nicht ins Repository gespeichert wird. Verbindungsabbrüche und mehrere, gleichzeitige Commits können somit nicht zu inkonsistenten Zuständen führen.
- Das Versionsschema von Subversion bezieht sich nicht mehr auf einzelne Dateien, sondern auf ganze Verzeichnisse. Bei jedem Commit erhöht sich die Revisionsnummer der Datei und aller "Super"-Verzeichnisse (vom Ordner, in dem die Datei enthalten ist, bis zum Wurzel-Ordner des Repository). Somit kann man einfacher eine exakte Version beschreiben (z. B. "Version 2841" statt "Version vom 23. März 2004 20:56:31 GMT"). Alle nicht geänderten Dateien behalten ihre Revisionsnummer (RNr.) bei. (Beispiel: Ordner "A" hat die Dateien "B" und "C". Wenn "B" die RNr. 10 und "C" die RNr. 14 hat, dann hat Ordner "A" die RNr. 14. Wäre "C" oder "B" auch ein Ordner, wäre es das gleiche.)
- Zusätzlich zu einem eigenen Server und der Speicherung im lokalen Dateisystem existiert auch ein Modul für den Apache 2 Webserver, mit dem die Daten auch mit der HTTP/HTTPS-Erweiterung WebDAV übertragen werden können.
- Einige Operationen (update, tagging, branching) sind deutlich schneller als bei CVS.
- Manche Operationen, welche bei CVS Zugriff auf das Repository benötigen, kommen bei Subversion ohne einen solchen Zugriff aus, da eine Kopie der BASE-Revision innerhalb des Arbeitsverzeichnisses gespeichert wird. Dadurch entfällt bei Remote-Repositories die Notwendigkeit eines Netzwerk-Zugriffs.
Nachteile gegenüber CVS
- Die gleichen Daten (z. B. nach Konvertierung) benötigen in einem Subversion-Repository deutlich mehr Platz als in einem CVS-Repository.
- Da im Arbeitsverzeichnis eine Kopie der BASE-Revision gehalten wird, benötigen Arbeitsverzeichnisse ungefähr den doppelten Platz.
- Subversion ist noch nicht so gut getestet wie CVS.
- Benötigt den Apache HTTP Server 2.0, wenn das WebDAV-Feature genutzt werden soll. Allerdings könnte man hier entgegnen, dass CVS WebDAV gar nicht unterstützt. Außerdem gibt es auch ein eigenes Protokoll, welches vergleichbar mit dem Netzwerkprotokoll von CVS ist.
Anmerkung zur Komplexität von Subversion
Subversion für sich ist nicht lauffähig. Es benötigt folgende zusätzliche oder vorhandene Subsysteme.
minimal:
- Apache Portable Runtime
- nur vor Version 1.1.0: Berkeley-DB 4.x
erweiterte Funktionalität:
- XML-Parser Expat
- Python 2.x
- Apache 2
- OpenSSL oder andere SSL-Implementation
- Neon
Nicht alle dieser Komponenten sind immer notwendig. Apache2 und Neon sind für die WebDAV-Nutzung notwendig; will man sie nicht verwenden, braucht man diese Pakete nicht. Python ist für einige mitgelieferte Skripte zum Testen notwendig, für die Lauffähigkeit des Basispakets ist es nicht notwendig. Eine SSL-Implementierung benötigt man für WebDAV, wenn man es verschlüsselt anbieten will. Für eine Installation der Basisfunktionalität ist seit Version 1.1.0 nur die Apache Portable Runtime-Bibliothek notwendig. Zuvor war auch noch eine Berkeley-DB notwendig, die seit Subversion 1.1.0 nicht mehr installiert werden muss, weil das Repository optional auch direkt im Dateisystem gespeichert werden kann (FSFS-Backend). Die angegebenen Komponenten müssen beschafft werden, in der korrekten Version vorliegen, in der richtigen Reihenfolge nachinstalliert werden und entsprechend konfiguriert und kompiliert werden, sollten sie nicht vorhanden sein. (Quelle: Linux Enterprise, 5.2003, S. 38 ff.) Allerdings kann man für Unix-Systeme auch fertige Pakete wie RPMs verwenden, die für die meisten Systeme vorhanden sind. Unter Windows liegt ebenfalls eine fertige Binärversion vor, die ohne großen Aufwand installiert werden kann.
Die Einrichtung eines Repositories besteht – wie beim Vorgänger CVS – aus dem Aufruf eines Befehls. Bei lokalem Zugriff kann man nun sofort loslegen. Will man Subversion als Server konfigurieren, hängt der Aufwand stark von der gewählten Methode ab, ist jedoch ähnlich mit dem anderer Systeme wie CVS.
Die Anwendung von Subversion ist für Laien ungeeignet, man benötigt Kenntnisse über Versionskontrolle, wie bei anderen Versionskontrollsystemen auch. Die Zielgruppe eines jeden Versionskontrollsystems sind jedoch Entwickler, von denen entsprechende Kenntnisse erwartet werden. Andere Stimmen sind genau der gegenteiligen Meinung, nämlich, dass es unnötig und auch nicht zumutbar ist, dass jeder Entwickler sich tiefere Administrator-Kenntnisse aneignen muss, bevor er als Entwickler mit svn arbeiten kann. Zitat: "Die Administration von svn unterscheidet sich natürlich grundlegend vom Gebrauch von svn als Benutzer" (Quelle: Linux Enterprise, 5.2003, S. 41)
GUI-Frontends / -Clients
- RapidSVN (Linux, Win32 ...) GUI-Frontend
- eSvn Qt-basierter Client
- JSVN Java-Swing-Client
- TortoiseSVN Windows-Explorer-Erweiterung
- AnkhSVN ein MS Visual Studio .NET addin.
- Subclipse ein Eclipse_(IDE)-Plugin
- Konqueror mittels svn-KIO-Slave