Zum Inhalt springen

Apache Subversion

aus Wikipedia, der freien Enzyklopädie
Subversion

Subversion-Logo
Basisdaten

Entwickler CollabNet
Erscheinungsjahr 20. Oktober 2000[1]
Aktuelle Version 1.5.4
(24. Oktober 2008)
Betriebssystem AIX, GNU/Linux, Windows, Mac OS X, *BSD, Solaris, OS/400
Programmier­sprache C[2][3], Python[2], C++[2], Java[2], Ruby[2], Perl[2]
Kategorie Versionsverwaltung
Lizenz Subversion License (ähnlich Apache/BSD)
deutschsprachig ja
subversion.tigris.org

Subversion (SVN) ist eine Open-Source-Software zur Versionsverwaltung von Dateien und Verzeichnissen.

Die Versionierung erfolgt in einem zentralen Projektarchiv (engl. repository) in Form einer einfachen Revisionszählung. Wenn Änderungen an Inhalten verteilt auf den Computern der Bearbeiter ausgeführt werden, werden zwischen dem Projektarchiv und einem Arbeitsplatz jeweils nur die Unterschiede zu bereits vorhandenen Ständen übertragen; anfangs das gesamte Projekt, später nur Änderungen.

Allgemeines

Subversion wird als Freie Software unter einer Lizenz im Stil der Apache-Lizenz veröffentlicht.

Die Benennung „Subversion“ verweist einerseits auf den politisch-soziologischen Begriff der Subversion und greift andererseits die Bedeutung von sub version im Sinne von Unterversion, früherer Version auf.

Subversion wurde als moderne Ablösung für das mit vielen Schwächen behaftete, in Entwicklerkreisen aber weiterhin sehr verbreitete Programm CVS entwickelt. Deshalb ist es in der Bedienung sehr ähnlich gehalten, behebt aber einige Schwächen von CVS. So ist es mit Subversion z. B. möglich, Dateien oder Verzeichnisse zu verschieben oder umzubenennen, ohne die Versionsgeschichte zu verlieren. Dies wird im Abschnitt Unterschiede zu CVS vertieft.

Mit cvs2svn existiert ein Konverter, mit dem ein CVS-Repository zu Subversion konvertiert werden kann. Auch für die Migration von anderen Versionsverwaltungs-Systemen (etwa PVCS, Visual Source Safe, ClearCase, MKS, Perforce, StarTeam, …) sind verschiedene kostenfreie Import-Werkzeuge erhältlich.

Geschichte

Subversion wird seit Anfang 2000 bei CollabNet entwickelt und erreichte am 23. Februar 2004 die stabile Version 1.0. Am 29. September 2004 erschien Version 1.1, deren größte Neuerung war, dass Projektarchive (Repositories) nicht mehr nur in einer Berkeley-Datenbank verwaltet werden können, sondern dass dazu auch direkt das Dateisystem benutzt werden kann. Außerdem wurden internationalisierte Programmausgaben ermöglicht. Die am 23. Mai 2005 erschienene Version 1.2 unterstützt nun auch optionale Bearbeitungssperren für Dateien, was teilweise für binäre Dateien von Vorteil sein kann. Seit dem 1. Januar 2006 existiert die Version 1.3, die in den Bereichen Server-Logging, Autorisierung, Programmiersprachen-Anbindungen, Kommando-Optionen und Leistung („Performance“) Verbesserungen bietet. Am 10. September 2006 wurde Version 1.4 veröffentlicht, sie bringt das Programm svnsync mit, welches das Spiegeln von Projektarchiven (Repositories) ermöglicht.

Unterschiede zu CVS

Der entscheidende Unterschied zwischen CVS und SVN liegt in der Rangfolge von örtlicher (L) und zeitlicher (T) Kennzeichnung der Inhalte eines Projektarchivs (P): während in CVS primär örtlich, sekundär zeitlich adressiert wird (P:L.T), werden in SVN die Koordinaten umgekehrt (P:T.L). SVN bildet die erfahrungsgemäße Realität von Veränderungen damit anschaulicher nach: Jede Veränderung benötigt Zeit, und ihre Endpunkte sind das Vorher (Revision vor Änderung) und das Nachher (Revision nach der Änderung). SVN versioniert oder revisioniert also grundsätzlich das gesamte Projektarchiv und damit jeweils die gesamte Verzeichnisstruktur, während CVS auf der unabhängigen Versionierung jedes einzelnen Inhalts beruht.

Das Versionsschema von Subversion bezieht sich nicht mehr auf einzelne Dateien, sondern jeweils auf das ganze Projektarchiv, mit jeder Änderung bekommt es eine neue „Revisionsnummer“ zugeordnet. Somit kann man einfacher – und im Gegensatz zu CVS konsistent – eine exakte Version beschreiben (z. B. „Revision 2841“ statt „Version vom 23. März 2004 20:56:31 UTC“). Die Revisionsnummer einer Datei entspricht dabei der Revisionsnummer des Projektarchivs, als sie das letzte Mal geändert wurde, die Revisionsnummer eines Verzeichnisses entspricht der höchsten Revisionsnummer der enthaltenen Dateien und Verzeichnisse. Die Abfolge der Revisionsnummern einer einzelnen Datei kann also durchaus lückenhaft sein, wenn die Datei nicht bei jeder Änderung (Commit) am Repository geändert wurde. Beispielsweise könnte eine Datei bei der Revision 25 zum Projektarchiv hinzugefügt worden sein und jeweils einmal in der Revision 48 und der Revision 52 verändert worden sein. Beim Abrufen ("checkout") einer Datei wird die größte Revisionsnummer abgerufen, die kleiner oder gleich der angeforderten ist. Wird in dem Beispiel die Revision 52 angefordert, so wird die Revision 52 der Datei abgerufen; wird hingegen die Revision 51 angefordert, liefert Subversion die Inhalte von Revision 48.

Subversion speichert Client-seitig beim Abrufen ("checkout"), Aktualisieren ("update") und Ändern ("commit") in einem gesonderten Verzeichnis (.svn) eine zweite Kopie jeder Datei. Dadurch verdoppelt sich der Speicherbedarf einer Arbeitskopie, allerdings bietet dies bei entfernten Projektarchiven auch einige Vorteile. So können einige Aktionen, wie Anzeige der lokalen Änderungen, ganz ohne Netzwerkzugriff erfolgen, und Subversion muss beim "commit" nur die geänderten Teile einer Datei übertragen, während CVS die Änderungen Server-seitig berechnet und somit jeweils die gesamte Datei übertragen muss. Auch ist es möglich, jederzeit die Änderungen einer Datei gegenüber ihrer Basisversion zu ermitteln oder zurückzunehmen, ohne das Projektarchiv zu konsultieren.

Änderungen ("commits") sind dabei in Subversion atomar, das heißt, eine Änderung wird entweder ganz oder gar nicht ins Repository gespeichert. Verbindungsabbrüche und mehrere gleichzeitige "commits" können somit nicht zu inkonsistenten Zuständen führen.

Kopien

CVS ist nicht in der Lage, Kopien von Dateien zu verwalten; jede Kopie wird wie eine ganz neue Datei behandelt. Subversion behält bei Kopien die Historie einer Datei. Bei der Erstellung einer Kopie wird dabei keine Duplizierung der Daten vorgenommen, sondern eine datenbankinterne Verknüpfung angelegt, die im weiteren Verlauf genauso weiter verwendet werden kann wie das Original („billige Kopie“). Kopien sind insbesondere beim Umbenennen und Verschieben von Dateien interessant. Subversion realisiert dies zwar wie CVS, indem es eine Kopie anlegt und das Original als gelöscht markiert, allerdings kommt es nicht wie in CVS zu einem Bruch in der Historie. Eine native Unterstützung für das Verschieben/Umbenennen ist auf der Website als mittelfristiges Ziel genannt.[4]

Tag- und Branchkonzept

Visualisierung eines Subversion-Projektes

Neben dem geänderten Datenbank-Modell sticht das zu CVS völlig unterschiedliche Konzept im Bereich des Tagging und Branching hervor. Während Tags und Branches in CVS eine klare semantische Bedeutung haben, kennt Subversion nur das Konzept der Kopie, die je nach Nutzungsart Tag- oder Branch-Charakter haben kann. Jede Kopie in Subversion ist demnach automatisch ein Branch dieser Datei oder des Verzeichnisses. Tags entstehen in Subversion, wenn man eine Kopie anlegt und später auf ihr keine Änderungen mehr vornimmt. Aufgrund des Fehlens einer Tag- und Branch-Semantik obliegt die Strukturierung und Verwaltung von Tags und Branches dem Benutzer und Administrator. Dabei hat sich bewährt, für Projekte die Basisverzeichnisse trunk (engl. Stamm), branches (engl. Verzweigungen) und tags (engl. Markierungen) anzulegen. trunk enthält dabei die Hauptentwicklungslinie des Projekts, in branches werden weitere Unterverzeichnisse mit alternativen Entwicklungspfaden verwaltet, und in tags eine Kopie von trunk oder einem der branches als Unterverzeichnis angelegt. Zur besseren Übersicht werden je nach Projektanforderungen tags und branches noch in weitere Unterverzeichnisse unterteilt. Als head bezeichnet man die Toprevision innerhalb eines Branches.

Durch das Fehlen einer aufgezwungenen Semantik für Tags ist bei gehobenen Ansprüchen an das Versionskontrollsystem die Angabe der Revisionsnummer als Referenz, beispielsweise beim Bug-Tracking oder in der Dokumentation, unabdingbar. Die Verwendung von serverseitigen Scripts kann steuern, ob, wie und von wem erstellte Tags modifiziert werden können. Darüber hinaus ist das Branchen und Taggen in Subversion deutlich performanter gelöst als in CVS.

Da Dateien in Subversion auch versionskontrolliert umbenannt werden können, kann die Projektstruktur jederzeit gestiegenen oder gesunkenen Anforderungen angepasst werden.

Sonstiges

Subversion kann auch Verzeichnisse und Metadaten verwalten. Insbesondere können Verzeichnisse auch als gelöscht markiert werden. Dies ist mit CVS nicht möglich, hier können nur optional leere Verzeichnisse gelöscht werden, sie können nicht ohne Verlust der Historie aller enthaltenen Dateien aus dem Repository gelöscht werden. Subversion bietet einen verbesserten Umgang mit Binärdaten. Es erkennt solche Dateien (beispielsweise Bilder oder Audiodateien) weitgehend automatisch, und es werden (wie bei Textdateien) nur die Differenzen zwischen den geänderten Versionen gespeichert. In CVS geht das umständlicher über Eintrag der Endungen von binären Dateien in cvswrapper, verschiedene Versionen von Dateien dieser Typen müssen aber immer voll gespeichert werden.

Wie CVS bietet Subversion den Netzwerkzugriff über einen eigenen Server, auf den mit SSH auch verschlüsselt zugegriffen werden kann. Zusätzlich hierzu 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. Somit kann die aktuelle Revision einer Datei auch mit einem gewöhnlichen Webbrowser abgerufen werden.

Einmal eingefügte (checked in) Dateien lassen sich nur noch mit großem Aufwand, teilweise sogar mit der Gefahr, das Repository zu zerstören, vollständig (mitsamt Versionshistorie) entfernen. [5] Für die Zukunft ist geplant, das Kommando svnadmin obliterate zu implementieren, welches ein sicheres und rückstandfreies Löschen ermöglichen soll [6], was allerdings seit inzwischen über einem halben Jahrzehnt nicht verwirklicht wurde.

Subversion verwaltet das gesamte Repository in einer Datenbank, deren Dateien nicht die Struktur des Repository-Inhalts widerspiegeln. Die Integrität der Datenbank lässt sich so verzeichnisübergreifend überprüfen. Es stehen dabei aktuell zwei Backends zur Verfügung. Das in der Version 1.1 hinzugefügte fsfs-Backend verwendet ein eigenes Format. Das andere Backend verwendet das Berkeley-Datenbanksystem, dies hat jedoch den Nachteil, dass die Daten einerseits dessen binären Inkompatibilitäten abhängig von der verwendeten Version unterliegen, und andererseits den damit eingebrachten Stabilitätsproblemen. Dies kann zur Folge haben, dass ein mit einer älteren Version erstelltes Repository auf die neue Version angepasst werden muss. Zudem ist der Zugriff über NFS und Windows-Netzwerkfreigaben dann nicht möglich.

Im Gegensatz zu CVS definiert Subversion die Zeichenkodierung, welche für Dateinamen und Log-Messages im Repository benutzt wird. Damit können beispielsweise auch Dateien mit Umlauten im Namen auf Systemen mit verschiedenen Zeichen-Codierungen (beispielsweise CP1252 (deutschsprachiges Windows), UTF-8 (Linux)) benutzt werden, während dies bei CVS nicht plattformunabhängig funktioniert, da die CVS-Client-Server-Protokoll-Definition dies nicht festlegt.

Die aktuelle Subversion-Version hat lediglich Probleme auf Mac OS X, da dessen Dateisystem z. B. Umlaute als zwei Zeichen speichert (etwa „a“ + „¨“[7]), während Windows und Linux nur ein Zeichen benutzen (etwa „ä“). Man kann die unter Mac OS X hinzugefügten Dateien zwar unter Windows abrufen, aber die Umlaute bestehen intern dann auch aus zwei Zeichen, werden aber wie „normale“ Umlaute beispielsweise im Explorer angezeigt. Da man trotzdem Dateien mit „normalen“ Ein-Zeichen-Umlauten anlegen kann, ist es so möglich, zwei gleich aussehende, aber intern vom Namen her unterschiedliche Dateien in demselben Verzeichnis unter Windows zu haben.

Abhängigkeiten von Subversion

Für eine Installation der Basisfunktionalität muss seit Version 1.1.0 nur die Apache Portable Runtime-Bibliothek vorhanden sein. Zuvor war auch noch eine Berkeley-DB in einer Version von 4.0 oder höher notwendig, was jetzt aber hinfällig ist, da das Repository mit Hilfe des FSFS-Backend optional auch direkt im Dateisystem gespeichert werden kann.

Apache 2 und Neon sind für die WebDAV-Nutzung erforderlich, Python 2.x für einige mitgelieferte Test-Skripte, eine SSL-Implementierung, wenn man WebDAV verschlüsseln will. Seit Version 1.4 kann alternativ auch Serf anstatt neon für WebDAV verwendet werden.

Die Einrichtung eines Repositorys besteht – wie bei 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 im Vergleich zu anderen Systemen, wie beispielsweise CVS.

Der Standard-Subversion-Port ist 3690.

Grafische Benutzeroberflächen

Es gibt einige ausgereifte grafische Benutzeroberflächen (GUI) für Subversion. Sie machen es den Benutzern besonders leicht, auf ein Subversion-Repository zuzugreifen. Hier einige Anwendungen:

Weiterhin sind Plugins für NetBeans, Eclipse, Code::Blocks, Vim, TYPO3, Microsoft Visual Studio und ASCET verfügbar. Die globale Administration (Benutzerrechte, Protokolle, …) erfolgt jedoch weiterhin über spezielle SVN-eigene Konfigurationsdateien.

Um ein Subversion-Repository lediglich zu betrachten, bieten viele Open-Source-Projekte einen Link auf ihren Webdienst an. Dieser präsentiert in übersichtlicher Form Inhalte von Dateien, Verzeichnissen und Logbüchern, auch Datei-Vergleiche sind möglich.

Literatur

  • Tobias Wassermann: Versionsmanagement mit Subversion, mitp-Verlag, 1. Auflage Oktober 2006, ISBN 978-3-8266-1662-4.
  • Frank Budzuhn: Subversion, Galileo Computing, 2. aktualisierte und erweiterte Auflage 2007, ISBN 978-3-89842-879-8.

Einzelnachweise

  1. ↑ subversion.apache.org.
  2. ↑ a b c d e f The subversion Open Source Project on Open Hub: Languages Page. In: Open Hub. (abgerufen am 29. Dezember 2023).
  3. ↑ projects.apache.org. (abgerufen am 8. April 2020).
  4. ↑ Subversion-Bugtracker: Issue 898
  5. ↑ Subversion-Bugtracker: Issue 516, 4. Oktober 2001
  6. ↑ Subversion FAQ: How do I completely remove a file from the repository's history?, 3. August 2006
  7. ↑ genauer: LATIN SMALL LETTER A + COMBINING DIAERESIS The Unicode Standard 5.0, Chapter 3.6 Combination
Abgerufen von „https://de.wikipedia.org/w/index.php?title=Apache_Subversion&oldid=52876663“