Subversion#

Subversion ist ein Versionskontrollsystem, mit dem mehrere Entwickler gleichzeitig auf einen Baum von Quelltexten (in einem sog. Repository) zugreifen können. Es tritt an, der Nachfolger des bekannten und bewährten CVS zu sein. (Siehe hierzu auch unsere KurzAnleitungCVS). Die besten Infos hierzu gibt es auf der Homepage des Projektes: http://subversion.tigris.org. Zur Benutzung von CVS und SubVersion speziell unter Debian-Linux ist auch http://qref.sourceforge.net/Debian/reference/ch-vcs.de.html ganz interessant.

Auf der Homepage gibt es ein sehr gutes Online-Handbuch. Eine Kurzanleitung haben wir auch im Web gefunden.

Obwohl eigentlich die o.g. Dokumentation keinerlei Wünsche offenlässt, gibt es doch immer etwas, was man doch noch dazu sagen kann oder was mir nach Studium der Doku noch unklar war. -- ThomasBayen

Einrichtung eines eigenen Repository#

Unter Debian Linux habe ich folgende Pakete installiert:

  aptitude install subversion libapache2-svn
Dann habe ich mit folgenden Befehlen ein Repository angelegt und dafür gesorgt, daß der Apache darauf zugreifen kann. Der Zugriff über den Apache Webserver bietet die komfortableste Möglichkeit, von anderen Rechnern auf das Repository zuzugreifen.
  mkdir /var/lib/svn
  mkdir /var/lib/svn/meinprojekt
  svnadmin create /var/lib/svn/meinprojekt
  chown www-data.www-data /var/lib/svn/ -R
In Datei /etc/apache2/mods-available/dav_svn.conf die Einträge DAV und SVNPath ent-kommentieren, den Pfad zum Repository durch meinprojekt ergänzen und ggf. den URL-Pfad anpassen. Dann Apache2 neu starten (/etc/init.d/apache2 restart). Nun kann man schon mit einem Webbrowser unter http://localhost/svn einen Blick in das leere Repository werfen.

Je nachdem, was man sonst noch in der Konfigurationsdatei des Apache-DAV-Moduls schreibt, muss man noch eine Benutzerdatei anlegen. Die in der Datei als Beispiel angegebene Basic Authentication ist schon alleine deshalb nicht sicher, weil die Passwörter im Klartext übertragen werden. Sie kann jedoch immerhin dazu dienen, bei einem normalen Projekt ohne große Sicherheitsanforderungen verschiedene Mitarbeiter auseinanderzuhalten. (Wer will, kann das übrigens auch ganz ohne Authentifizierung konfigurieren.) Sichere Passwortdateien kann man mit dem Kommando htpasswd2 erzeugen (siehe manpage).

Tags und Branches#

Wer in der Vergangenheit mit Branches und Tags bei CVS gearbeitet hat, wird merken, daß das etwas anders funktioniert. Wer noch nicht damit gearbeitet hat, weil er ein bisschen Angst vor dem Thema hatte, wird überrascht sein, wie leicht das Thema bei Subversion auf einmal zu begreifen ist. Wer nicht weiss, ob er in der Zukunft einmal Tags benötigt, sollte auf jeden Fall auch weiterlesen, weil man beim Anlegen von Repositories ein kleines bisschen vorausschauend arbeiten kann. Frei nach dem KISS-Paradigma gibt es nämlich in Subversion beide Eigenschaften nicht. Dafür kann man sie selber ganz einfach erzeugen, wenn man weiss, daß Subversion auch das kopieren von Dateien versioniert.

Tags#

Ein Tag ist eine Kopie eines Repositories zu einem bestimmten Zeitpunkt. Wenn ich will, daß mein heutiger Stand für alle Zeiten als "Version2005" in Erinnerung bleibt, setzte man dazu mit CVS ein "Tag". Da Subversion allerdings auch das Kopieren von Dateien versionsgerecht unterstützt, geht das hier viel einfacher: Ich kopiere das Original-Sourceverzeichnis einfach innerhalb des Repositories an eine andere Stelle. Die Kopie benötigt keinen eigenen Speicherplatz, weil Subversion ja "weiss", daß es nur eine Kopie des jetzigen Versionsstandes ist. Daher ist eine solche Kopie sehr "billig" (bzgl. Speicherverbrauch), d.h. genauso billig, wie das setzen eines Tags in CVS. Da man jederzeit auch einzelne Verzeichnisse auschecken kann, kann man sich nun aussuchen, ob man das Ursprungs-Verzeichnis oder ein beliebiges Kopie-Verzeichnis (also z.B. "Version2005") auschecken will.

Branches#

Wenn wir nun eine solche Tag-Kopie verändern und wieder einchecken, haben wir genau das, was man bei CVS einen "Branch" nennt. Fertig! Wenn man darüber nachdenkt, merkt man, wie unkompliziert das eigentlich ist. Will man einen solchen Branch wieder in den Hauptstrang "mergen", sollte man übrigens nochmal die Doku zu rate ziehen, damit man keine Fehler macht und wirklich alle Änderungen übernimmt.

Erkenntnisse hieraus#

Hieraus folgt nun die Erkenntnis, daß man, wenn man diese Funktionen nutzen will, Unterverzeichnisse benötigt, in denen man dann die Kopien erzeugt. Daher ist es sinnvoll, sich bei der Erzeugung eines Repositories hierüber Gedanken zu machen und z.B. die Grundverzeichnisse trunk, branches und tags anzulegen. Dies wird im Grunde auch in der Doku so gemacht, aber IMO nicht hinreichend erklärt. Man kann diese drei Verzeichnisse als Unterverzeichnisse seines Projekt-Verzeichnisses anlegen, um dem Beispiel des Handbuchs zu folgen. Im Prinzip handelt es sich hierbei jedoch nur um eine Konvention. Man kann also z.B. auch obige Verzeichnisse im root-Verzeichnis oder die Hauptstämme im root-Verzeichnis des Repositories anlegen und die Branches in /branches usw. -- ThomasBayen

Subversion und Eclipse#

Von Haus aus bringt Eclipse Teamfunktionen mit, damit mehrere Entwickler ein Projekt gemeinsam bearbeiten können. Diese integrierten Teamfunktionen bauen auf CVS (Concurrent Versioning System) auf. Es gibt aber auch ein Plugin, um Subversion wie CVS in der EclipseIDE benutzen zu können. Hierbei werden alle Vorteile von Subversion genutzt, d.h. wer mit Eclipse z.B. eine Datei verschiebt, erzeugt damit auch eine echte (versionierte) Kopie im Repository (für CVS wäre das eine gelöschte und eine neue Datei). Die Homepage des Plugins ist http://www.eclipse.org/subversive/. Wie in der Installationsanleitung beschrieben, wird ein neuer Update-Server eingetragen und dann die neuen Features installiert.

  • es hat sich ein wenig was geändert, man brauch zum laufen des SVN plugin auch einen SVN connector SVNKit version 1.1.7 kann mit SVN bis version 1.4 umgehen der 2.x beta connector kann version 1.5 und mit svnjavah habe ich keine erfahrung die installation ist mir zu aufwendig (das andere geht ja)

Zu beachten ist lediglich, daß man, wenn man Projekte neu anlegt, die o.a. Verzeichnisstruktur auch erzeugt, weil diese ja nicht Teil des Eclipse-Projektes ist. Neuere Eclipse-Versionen bieten an, diese Struktur direkt richtig zu erzeugen.

Für ältere oder "Handarbeiter" bietet es sich ggf. an, das Grundgerüst eines neuen Projektes erstmal über die Kommandozeile anzulegen:

  mkdir /tmp/leer
  mkdir /tmp/leer/Projektname
  svn import . http://svn.meinserver.loc/svn/ -m "Projektverzeichnis anlegen"
Danach kann man beim Erzeugen eines SVN-Repositories in Eclipse als Name (statt den Projektnamen zu nehmen wie vorgegeben) Projektname/trunk angeben. (Natürlich sind aber auch Repository-Layouts denkbar, bei denen das nicht nötig ist, wenn z.B. nur die Branches in ein Sonderverzeichnis kommen, die Trunks aber in die von Eclipse vorgegebenen...)

svn cleanup in Eclipse#

Übrigens funktioniert bis heute (Oktober 2008) der "cleanup"-Befehl von Eclipse aus nicht richtig. Hin und wieder komme ich in Situationen (wie ich das gemacht habe, weiss ich nicht), wo ein Commit oder ein Update nicht richtig funktioniert, z.B. weil angeblich mein Projektverzeichnis gelockt ist. Eclipse empfiehlt in diesem Fall ein "cleanup". Ebendieses steht auch im Team-Menü, funktioniert aber nicht immer. :-) Ein kurzes svn cleanup auf der Kommandozeile kann da Wunder wirken. -- ThomasBayen

Webinterface#

Einer der Vorteile, wenn man das Apache-DAV-Modul benutzt, um Subversion als Server laufen zu lassen, ist die Webschnittstelle, die es gratis dazu gibt. Allerdings kann man damit nur einfach in einer Verzeichnisansicht lesend auf die jeweils aktuelle Revision zugreifen. Eine richtige Weboberfläche ist z.B. WebSVN. Dieses kann man mit

  aptitude install websvn libapache2-mod-php4
(Das zweite Paket ist nur unter Debian Sarge nötig, weil der Paketmanager sonst evtl. versucht, webdav für den Apache 1.x zu konfigurieren und das ist blöde, wenn wir den Apache2 eh schon installiert haben.)

Bei der Konfiguration des Debian-Pakets kann man im ersten Eingabefeld ein Verzeichnis angeben, in dem mehrere Repositories sind und im zweiten einzelne Repositories. Dadurch ist man sehr flexibel bei der Auswahl. Ein Blick auf die URL http://myhost/websvn mit dem Webbrowser und die ganze Pracht von websvn steht zur Verfügung.

Backups#

Das Dateiformat von Subversion ist nicht spezifiziert und von der Subversion-Version sowie der Datenbankbibliothek anhängig. So ist ein Repository, daß auf einer i386-Architektur erzeugt wurde, nicht ohne weiteres auf einem amd64-System zu benutzen.

Um für solche Fälle ein Backup (bzw. ein Migrationsformat) zu haben, gibt es die Befehle svnadmin dump ... sowie svnadmin load .... Bei einer Migration muss man als auf dem alten Sysstem eine Dump-Datei erzeugen, die man dann auf dem neuen System wieder einspielen kann. (Blöd, wenn das alte System gerade abgeraucht ist, wie bei mir, aber was soll ich hier über BackupServer sagen...)

svnadmin dump #

Das Kommando svnadmin dump erzeugt ohne weitere Optionen ein Full-Backup des gesamten Repositories. Die Option -r 100:199 schränkt den Backup auf die Revisionen 100 bis 199 ein, dabei ist die Revision 100 vollständig im Backup enthalten. Die Zusatzoption --incremental sorgt schließlich dafür, dass auch für die erste Revision im Dump nur ein Delta gespeichert wird.

Die folgende Befehlsfolge erzeugt also einen vollständigen SVN-Dump für die Revisionen bis einschließlich Revision 3000, der auf drei Dateien aufgeteilt ist:

   $ svnadmin dump myrepos -r 0:1000 > dumpfile1
   $ svnadmin dump myrepos -r 1001:2000 --incremental > dumpfile2
   $ svnadmin dump myrepos -r 2001:3000 --incremental > dumpfile3

svnsync#

Mit dem Kommando svnsync läßt sich eine Read-Only-Kopie eines Repositories Up-To-Date halten.

$ svnsync initialize http://svn.example.com/svn-mirror \
                     http://svn.collab.net/repos/svn \
                     --sync-username syncuser --sync-password syncpass
Copied properties for revision 0.
$ svnsync synchronize http://svn.example.com/svn-mirror
Transmitting file data ........................................
Committed revision 1.
Copied properties for revision 1.
Transmitting file data ..
...
Transmitting file data ..
Committed revision 23408.
Copied properties for revision 23408.
$

Alternativen#

Andere interessante Versions-Kontrollsysteme, die sich anzusehen eventuell lohnen könnte, sind:

--PeterHormanns, 18-Sep-2007

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-19) was last changed on 23-Jun-2009 11:02 by ThomasBayen