Thomas Kramer

IT-COW | All posts tagged 'Subversion'

Subversion und TortoiseSVN

By Administrator at August 10, 2010 16:42
Filed Under: Administration, Anleitungen, Linux, Windows

Subversion ist ein freies Quellcodeverwaltungssystem und sehr verbreitet bei OpenSource-Projekten, im Internet lässt sich viel Dokumentation dazu finden. Wenn man nach der Definition von Wikipedia geht könnte man die Software wohl auch als Collaboration Software einordnen, auch wenn man gemeinhin damit eher Software wie Outlook/Exchange oder auch Sharepoint meint:

 

Als Groupware bzw. Gruppen-Software (auch kollaborative Software) bezeichnet man eine Software zur Unterstützung der Zusammenarbeit in einer Gruppe über zeitliche und/oder räumliche Distanz hinweg.

 

Als Alternativen zu Subversion werden z. b. hier Rational ClearCase (kenne ich) oder auch Merant PVCS (kenne ich auch) genannt. Für Subversion scheint TortoiseSVN der verbreitetste Client mit UI zu sein, zumindest unter Windows. Leider bietet TortoiseSVN aber nur eine Explorer-Integration, für eine direkte Einbindung in IDEs wie Visual Studio oder Eclipse werden Zusatz-Programme wie RocketSVN (Visual Studio) oder Subclipse (Eclipse) benötigt.

 

Folgende Server laufen übrigens mittlerweile auf meinem Linux-System: OpenLDAP, Samba, CUPS, Apache, DokuWiki, eGroupWare, Bugzilla, PostgreSQL und MySQL, Icinga ... auf meinem Windows-Server arbeiten dagegen folgende Server-Dienste: FTP, SMB, Apache, CopSSH, hMailServer, SquirrelMail, Firebird, SQLServer und SharePoint Services, regain, Everything sowie ein Ubuntu Server in einer VM... Auf meinem Arbeits-PC laufen zusätzlich noch Oracle und VMWare Server, über das meine alte Notebook-Installation aufrufbar ist (VMWare Converter). XenServer hatte ich danach auf diesem Notebook installiert, aber 2GB RAM waren dafür etwas wenig.

 

Für Subversion gibt es sehr viel Dokumentation im Internet, insofern wird das keine vollständige Anleitung werden, eher ein Überblick und Reminder.

 

Installation von Subversion und TortoiseSVN

 

Die Installation von Subversion findet folgendermaßen statt

 

apt-get install subversion

 

und benötigt ca. 6 MB Speicherplatz. Das Apt-System von Debian-Linux-Derivaten ist schon genial, schade das es etwas vergleichbares für Windows nicht gibt. Folgende Pakete werden automatisch mitinstalliert:


libneon27-gnutls

libsvn1

 

Dadurch wurde bei mir Version 1.5.4 installiert, siehe auch die Homepage des Projekts: Link. Die Installation von TortoiseSVN unter Windows muss man nicht beschreiben, da muss man einfach immer auf weiter klicken - benutzte Version bei mir ist 1.6.10. Etwas lästig ist das man nach der Installation Windows neu booten muss.

 

Inwieweit das bei Windows-Software wirklich immer nötig ist bezweifle ich manchmal... bei mir war das eine Update- und keine Neuinstallation, aber auch nach dem Neustart waren keine TortoiseSVN-Kontextmenü-Einträge mehr vorhanden. Scheinbar scheint das öfters aufzutreten -> Link, nach einer weiteren Reparatur-Installation waren die Einträge dann wieder vorhanden.

 

TortoiseSVN klinkt sich also in die Kontextmenü-Einträge vom Windows-Explorer ein, um die Client-Funktionalität von Subversion abzubilden. Es werden aber auch Server-Funktionen unterstützt wie das Erstellen eines Repositories.

 

Zurück zu Subversion, was als erstes gemacht werden muss ist das Erstellen eines Repository auf dem Server:

 

mkdir -p /var/local/svn

svnadmin create --fs-type fsfs /var/local/svn

 

Den Pfad habe ich mit /var/local/svn bei mir auch übernommen... hier übrigens ein Link mit der Erklärung zur Linux-typischen Verzeichnisstruktur: Link. Damit man ungefähr weiss wo man das Repository speichern könnte...

 

Was mich bei meinen Recherchen etwas gestört hat ist das die meisten Anleitungen für den WebDAV-Zugriff zugeschnitten sind (Zugriff via Apache übers http-Protokoll), ich würde aber an erster Stelle den Zugriff über das svn-Protokoll konfigurieren. Es gibt demnach verschiedene Möglichkeiten für einen Zugriff:

 

  • http-Protokoll (WebDAV-Zugriff)
  • https-Protokoll (WebDAV mit Verschlüsselung)
  • svn-Protokoll
  • svn+ssh (mit Verschlüsselung)

 

und Zugriff auf eine Netzwerkadresse über file:// ist theorethisch auch möglich, dazu muss aber ein Fileserver konfiguriert sein (wird aber von abgeraten -> Link).

 

Am verbreitetsten scheint der Zugriff über http zu sein - für http wird ein Apache-Server mit dem Modul dav_svn benötigt, für das svn-Protokoll dagegen ein laufender svnserve-Dämon. Das Modul dav_svn benötigt seinerseits aber keinen svnserve-Dämon, das habe ich explizit getestet (man kann ja den svnserve-Prozess abschiessen um das zu testen).

 

Die Zugriffsarten über Apache und svnserve laufen problemlos nebenher, man muss dann aber bei der Rechtevergabe aufpassen, weil die jeweils separat konfiguriert werden. Die Installation von dav_svn reicht übrigens nicht aus um ein Repository über den Webbrowser einsehen zu können, dazu benötigt man zusätzlich noch das Programm WebSVN. Soweit wird mein Exkurs aber nun nicht gehen, das benötige ich auch nicht.

 

svnserve ist standardmäßig bei Subversion mit dabei, dav_svn ist im Lieferumfang von Apache enthalten.

 

Konfiguration von Subversion

 

a) svnserve

 

Wie erwähnt muss man da je nach Zugriffsart unterscheiden. Für svnserve sieht die Konfiguration und Rechtevergabe folgendermaßen aus, es gibt in /var/local/svn/conf drei grundlegende Konfigurationsdateien:

 

svnserve.conf - das ist die primäre Konfigurationsdatei. Dort werden die grundlegenden Einstellungen vorgenommen und zwei weitere Dateien inkludiert, deren Auskommentierung muss man entfernen wenn man eine detailliertere Benutzersteuerung will. Übrigens sind die jeweiligen Kommandos in Kommentarzeilen erklärt.

 

Es gibt bei Subversion offenbar nur 3 verschiedene Rechte-Arten -> kein Zugriff, lesender Zugriff und Lesen+Schreiben - ein explizites Löschen-Recht gibt es nicht, Lesen+Schreiben beinhaltet also auch das Recht zu löschen.

 

authz - in der Datei werden Benutzer, Gruppen und deren Zugriffsrechte auf Repositories definiert - es besteht die Möglichkeit die Zugriffsrechte je nach Repository-Pfad verschieden zu handhaben, sogenanntes Path-Based Access Control. Davon wird aber hier im Block Do You Really Need Path-Based Access Control? deutlich abgeraten, sollte aber für kleinere Programmierer-Teams auch eher irrelevant sein.

 

Der Aufbau erinnert an ini-Dateien unter Windows, mit [] wird der Aufbau festgelegt. Entsprechend gibt es Blöcke mit [aliases], [groups]... für die Konfiguration eines pfadbasierenden Zugriffs muss man einen Block mit

 

[/Pfad]

 

deklarieren und darunter Benutzern Rechte zuweisen. Der Pfad bezieht sich auf das Stammverzeichnis, wenn man also im Repository ein Verzeichnis test hat, gibt man einfach [/test] oder eben [/] für den Stamm-Pfad an. Theorethisch gibt es die Möglichkeit einen Namen des Repositories anzugeben mit

 

[Name:/Pfad]

 

aber in meinen Tests hat der Zugriff dann nicht mehr funktioniert. Offenbar hatten andere damit auch Probleme: 1 2. Weiter recherchieren wollte ich das nicht, erstens unwichtig und zweitens gehört zum effizienten Arbeiten dazu das man nicht alles bis in das kleinste Detail recherchiert sondern sich auf das wesentliche konzentriert...

 

Aber wie erwähnt wird von pfadbasierter Konfiguration abgeraten und man sollte einfach einen [/]-Block deklarieren. Mit @ wird eine Gruppe referenziert und wenn man eine Zuweisung leerlässt wird kein Recht zugewiesen.

 

Passwörter werden dann in der Datei passwd zugewiesen, ganz einfach mit Benutzer = Passwort, die Passwörter sind im Klartext einzutragen. Nach vorgenommener Konfiguration svnserve starten mit  

 

svnserve -d -r /var/local/svn

 

Für das automatische Mitstarten beim Booten des Systems sollte eine Verlinkung zum Init-Skript in die Runlevel-Verzeichnisse hergestellt werden, siehe hier: Link.

 

b) dav_svn (Apache)

 

Das Apache bereits installiert ist, davon gehe ich einmal aus. Das Modul dav_svn muss mit

 

a2enmod authz_user

a2enmod dav

a2enmod dav_svn

 

erst aktiviert werden. Anschließend muss man die Rechte für den Apache-Benutzer aufs Repository vergeben:

 

chown -R www-data:www-data /var/local/svn


Im Verzeichnis /etc/apache2/mods-available/ gibt es (u. a.) die Konfigurationsdatei dav_svn.conf, die Auskommentierungen dort sollten weggenommen werden... die Datei erstellt eine URL für Apache, wenn als

 

<Location /svn>

 

dort angegeben ist, ist anschließend über http://$IP-Adresse$/svn das Repository verfügbar. Bei svnserve gibt es dagegen kein grundlegendes Suffix in der Adresse, der Repository-Stamm ist bei svn-Zugriff immer direkt über svn://$IP-Adresse$/ erreichbar.

 

Jedenfalls, die Datei dav_svn.conf inkludiert die Benutzerdatei /etc/apache2/dav_svn.authz und die Passwortdatei /etc/apache2/dav_svn.passwd. Ansonsten ist die Datei wieder gut erklärt in den (englischen) Kommentarzeilen.

 

In der dav_svn.authz werden Benutzer erstellt und ihnen Rechte zugewiesen, auf ein Verzeichnis im Repository oder global. Der Aufbau ist identisch zu der authz-Datei von svnserve. Die Passwörter werden verschlüsselt in die Passwort-Datei eingetragen, das geschieht automatisch über folgenden Befehl:

 

htpasswd -cm /etc/apache2/dav_svn.passwd testuser

 

Benutzung von TortoiseSVN

 

Danach kann man in TortoiseSVN auf ein Repository zugreifen, einfach Rechtsklick auf ein Verzeichnis und im Kontextmenü TortoiseSVN/Repo-browser auswählen und dort die Adresse eingeben. Wenn kein Zugriff über die IP-Adresse des Rechners erfolgen soll muss gegebenenfalls noch ein DNS-Server konfiguriert werden... nach meinen Tests läuft der Zugriff auf einen Fileserver über den Rechnernamen auch ohne DNS-Server (der automatisch im Netzwerk erstellte Master-Browser reicht dafür aus), aber bei einem Zugriff über eine URL-Adresse (ohne IP, über einen Namen eben) hört es dann auf, dafür muss ein DNS-Server erstellt werden.

 

Da ich auf meinem Arbeits-PC bereits TortoiseSVN installiert hatte, gab es entsprechend bereits eine Verknüpfung eines Verzeichnisses zu einem Server. Weil der Subversion-Server neu aufgesetzt wurde, wollte ich die Bindung des Verzeichnisses zuerst ändern oder entfernen, was aber mit einer Fehlermeldung quittiert wurde. Die Lösung dazu ist nicht so offensichtlich gewesen - über das Kontextmenü gibt es zwar die Funktionen Switch und Relocate, wobei Switch sich wohl darauf bezieht auf einen anderen Zweig (Branch) des Repositories zu wechseln und mit Switch auf einen anderen Server gewechselt werden kann.

 

Ich hatte aber nicht das Repository auf einen anderen Rechner verschoben sondern neu erstellt (ich rede vom Client) - dementsprechend hatte das neue Repository auch einen anderen internen Kennzeichner (Repository uuid). Die Lösung ist aber einfach gewesen, es musste nur das .svn-Unterverzeichnis gelöscht werden.

 

Anschließend habe ich mit dem Befehl Import die Dateien des Verzeichnisses wieder in das Repository kopiert. Die erreichte Datentransferrate ist für ein Gigabit-Netzwerk eigentlich recht enttäuschend gewesen, mehr als 200-500kb/sec konnten nicht erreicht werden. Eine prozentuale Fortschrittsanzeige fehlt in dem Dialog vielleicht noch.

 

Mit dem Befehl Export können analog die Dateien wieder heruntergeladen werden, wobei damit noch keine Verknüpfung des Verzeichnisses zum Server geschieht, das passiert erst mit dem Befehl SVN Checkout, erst dann stehen alle Funktionen von TortoiseSVN zur Verfügung.

 

Es ist aber auch eine sanftere Migration möglich, also dem Umzug eines Repositories auf einen anderen Server ohne die Historie zu verlieren: 1 2.

 

Bei den verschiedenen Zugriffsmöglichkeiten habe ich feine Unterschiede festgestellt: beim Zugriff aufs Repository über das http-Protokoll musste ich mich nicht einloggen für Schreib-Zugriff, wenn der Benutzer des Subversion-Moduls von Apache gleichlautend zum Windows-Benutzer des aufrufenden Clients (inkl. Passwort) war - beim schreibenden Zugriff übers svn-Protokoll musste ich mich dagegen erst einloggen, egal wie der Benutzer lautete. Und irgendwie kann ich über das svn-Protokoll ein gerade eben erstelltes Verzeichnis nicht wieder löschen (obwohl gleicher Eigentümer und Schreibrecht), das ging nur bei Zugriff über http. Zusammenfassend ist wohl auch WebDAV-Zugriff (http) zu bevorzugen. Für Tests empfehle ich übrigens beim LogIn-Dialog Save Authentication deaktiviert zu lassen.

 

Ansonsten muss natürlich Groß/Kleinschreibung des Verzeichnisses im Repository sowie des Apache-Präfix bei WebDAV-Zugriff beachtet werden.

 

TortoiseSVN komplett zu beschreiben würde natürlich den Rahmen sprengen, mache ich auch nicht. In den Settings können grundlegende Eigenschaften wie Sprache, Zugriff auf Proxy-Server, welches Diff-|Merge-Tool benutzt werden soll (TortoiseSVN bringt ein eigenes mit, aber an die Stelle hat sich bei mir KDiff in die Konfiguration geklinkt) oder auch das Global Ignore Pattern (welches festlegt welche Dateitypen ausgelassen werden sollen) definiert werden.

 

Grundsätzlich ist das System etwas anders als damals Rational ClearCase, es wird nicht der schreibgeschützt-Status der Dateien verändert. Es stehen erst dann alle Funktionen zur Verfügung wenn man das ganze Repository auf ein Verzeichnis ausgecheckt hat - die veränderten Dateien werden dann mit Commit wieder hochgeladen, aber eben nur diese Dateien. Das heisst der Default-Zustand ist das die Dateien ausgecheckt sind oder anders formuliert ein Checkout bezieht sich immer auf das gesamte Repository.

 

Bei ClearCase hat man dagegen nur die Dateien ausgecheckt die man gerade bearbeiten wollte, dadurch wurde der Schreibschutz dieser Dateien entfernt, und nach der Bearbeitung hat man die Dateien wieder eingecheckt. Insofern etwas unterschiedlich zu Subversion oder zumindest die Definition des Wortes "Auschecken" ist eine andere.

 

Es können Änderungen mit Revert wieder rückgängig gemacht werden, Dateien gelockt, Patch-Dateien (Diffs) erzeugt werden, veränderte Dateien gesucht werden, das ganze Verzeichnis auf einen bestimmten Revisionsstand gebracht werden, Dateien gemergt oder in einem Revision-Graph die Historie durchleuchtet werden... entspricht weitestgehend auch meinen Erwartungen an ein Quellcodeverwaltungssystem.

 

Weitere Links

 

  • Buch Versionsmanagement mit Subversion: Link
  • Subversion-Tutorial: Link
  • Versionsverwaltung mit Subversion: Link
  • Versionsverwaltung mit Subversion und TortoiseSVN: Link
  • Subversion Quickstart: Link
  • Subversion mit Webaccess aufsetzen: Link
  • Subversion aufsetzen: Link
  • Kommandozeilen-Befehle von Subversion: Link
  • Creating and Applying Patches: Link
  • Apache-Konfiguration für Subversion: Link
  • TortoiseSVN-Tutorial: Link
  • originale TortoiseSVN-Anleitung: Link
  • Versionskontrolle mit Subversion: Link (weitgehend identisch zu der englischen Anleitung von TortoiseSVN)

 

  • Subversion und WebSVN auf Debian (englisch): Link
  • Ubuntu-Integration: Link

 

Monats-Liste