Dieser Bericht soll beschreiben, wie meine ersten Erfahrungen mit Subversion sind und anderen eine kleine Einführung und vielleicht auch Hilfestellung geben.
Features und Vorteile gegenüber CVS
Als erstes soll betrachtet werden, welche Features Subversion bietet und vor allem was einen Umstieg von CVS rechtfertigt.
Versionierung von Verzeichnissen
CVS kann nur einzelne Dateien Versionieren. Subversion bietet ein virtuelles versioniertes Dateisystem das Änderungen von ganzen Verzeichnisstrukturen protokolliert. Es werden also Dateien und Verzeichnisse versioniert.
Volle Versionshistory
Dateien und Verzeichnisse können mit Subversion im Gegensatz zu CVS umbenannt, kopiert und verschoben werden. Die Versionierungsinformationen bleiben dabei erhalten.
Atomic commits
Änderungen gehen entweder vollständig ins Repository oder gar nicht.
Versionierte Metadaten
Es ist möglich frei definierte Metadaten zu Dateien und Verzeichnissen zu speichern. Dies ermöglicht dem Programmierer selbst Key-Value-Paare zu definieren, die ebenso wie die Dateien und Verzeichnisse selbst mit versioniert werden. Wozu dies genau nützlich sein kann, ist dem Autor nicht bekannt.
Flexibilität im Netzwerklayer
Subversion ist nicht mehr nur beschränkt als Betrieb als eigener Server, wie CVS das war, sondern kann einfach in andere Serveranwendungen wie z.B. den Apache Webserver integriert werden. Dies ermöglicht das Benutzen dieses ausgereiften Servers sowie der Features die noch geboten werden, wie Autorisierung, Kompression usw. Ein eigenständiger Server ist natürlich weiterhin vorhanden.
Konsistente Behandlung der Daten
Anders als in CVS wird von Subversion ein Algorithmus verwendet, der gleich funktioniert für Binärdateien und Textdateien.
Effizientes Branching und Tagging
Subversion erstellt Branches und Tags durch einfaches Kopieren des Projekts. Diese Operation verbraucht einen kleinen, konstanten Zeitrahmen.
Installation
Installationsprozess unter FreeBSD
/usr/ports/devel/subversion
make
Probleme gab es bei mir mit der Abhängigkeit neon. Diese ließ sich wegen einige Problemen mit expat nicht installieren. Ich habe das Problem umgangen indem ich in /usr/ports/www/neon im Makefile die Zeile geändert habe:
von:–with-expat \
in: –with-libxml2 \
Dokumentation und Benutzung von Subversion
Dokumentation gibt es in verschiedenen Formaten unter:
http://svnbook.red-bean.com/en/1.1/index.html
Allgemeines
- Subversion kann wohl verschiedene einstellbare Backends zur Speicherung der Daten verwenden. Gelesen habe ich bishet Berkley-DBs und FSFS.
Einrichten eines Subversion-Repository
Nach der Installation muss man zuerst ein Repository erstellen das dann die Verwaltungsdateien enthält. Das geht so:
svnadmin create /home/svnroot
Danach kann man mittels einer Reihe von Dateien ein neues Projekt anlegen. Für den Import eines Subversion-Projektes sollten die Source-Files ganz oben die folgenden directories haben:
/tmp/project/branches
/tmp/project/tags
/tmp/project/trunk
In trunc sollten sich dann die eigentlichen Dateien befinden. Den Sinn habe ich bisher noch nicht herausfinden können.
Das Importieren der Dateien funktioniert dann so:
svn import ./ file:///home/svnhome/ -m "initial import"
Checkout anlegen
Um arbeiten zu können muss man sich zunächst ein Checkout, eine Arbeitskopie anlegen:
svn checkout file:///home/svnhome/trunk modules
Mein Projekt-Verzeichnis war in diesem Falle modules. Wenn dies so ausgeführt wird, wird im aktuellen Verzeichnis ein Verzeichnis modules angelegt. Darin befindet sich wiederum ein Verzeichnis modules, was ich etwas unschlüssig finde.
Diffs
snv diff
Dieser Befehl liefert eine schöne Übersicht über die getätigten Änderungen
Commit
Konflikte lösen:
Das funktioniert in der Shell fast genauso wie bei cvs mit der Verbesserung, dass man mal direkt sieht, was die eigenen Änderungen sind und welche von remote kamen. Das war ja vorher immer fraglich und man hat jedes mal aufs neue gerätselt.
Hier ein Beispiel eines Konfliktes:
< <<<<<< .mine
# nur ein kleines kommentar
=======
# Hm, das sollte jetzt mal einen ordentlichen konflikt geben
# auch noch mehrspaltig
>>>>>>> .r2
Hat man einen Konflikt gelöst, dh. die Datei mit Konflikt so geändert, das sie korrekt ist, muss man den Konflikt mittels cvs resolved als gelöst markieren:
svn resolved modules/WiP.pm
Resolved conflicted state of 'modules/WiP.pm'
Netzwerkschnittstelle
Natürlich muss der Zugriff auf den Subversion-Server über das Netzwerk erfolgen können.
Zum Zugriff muss der Client die Url zum Server und den vollen Pfad zum Repository angeben:
svn://host.example.com/usr/local/repositories/project1
Will man das verhindern, kann man den Zugriff auf bestimmte Verzeichnisse im Server festlegen:
svnserve -d -r /usr/local/repositories
Die Option -r beschränkt auf bestimmte Verzeichnisse. Der Remote-Zugriff sieht dann so aus:
$ svn checkout svn://host.example.com/project1
Pro Repository kann festgelegt werden, wie der Zugriff erfolgt.
Integration in Eclipse
Eclipse-Support
Plugin: Subeclipse:
A Subversion Eclipse Plugin
http://subclipse.tigris.org/
Migration von CVS zu Subversion
Es gibt verschiedene Konverter eines CVS-Repository in ein Subversion-Repository. Eines davon ist cvs2svn. Dieses unterstützt verschiedene Arten der Konvertierung, begonnen vom Übertragen des aktuellsten Standes wobei die Historie verloren geht, bis hin zur vollen Konvertierung, die auch Branches und Tags und damit die volle Historie konvertieren kann.
Fazit
Subversion in der Shell erinnert sehr stark an cvs. Die meisten Kommandos wurden mit leichten Modifikationen übernommen. Ein Programmierer, der sich mit Shell-Bedienung von CVS auskennt, sollte keinerlei Probleme haben, sich an Subversion zu gewöhnen.
";