Quickstart: Versionskontrolle mit Subversion

Linux Quickstart: Versionskontrolle mit Subversion

Bei jedem Software-Projekt stellt sich die Frage, wie man den Überblick über die Änderungen an seinen Quelldateien behalten will und kann. Daher haben früher schon findige Programmierer ein Programmsystem entwickelt, welches einen sehr großen Teil der dafür notwendigen Arbeit abnimmt: CVS. Dies hat aber nach wie vor einige Macken. Subversion ist sein verbesserter Nachfolger.

Bei CVS können Dateien nicht einfach umbenannt werden und auch die Versionsverwaltung von anderen Dateiformaten als reinem Text war nicht vorgesehen. Mit diesen Problemen räumt nun der Nachfolger [LINK:START:348]Subversion[LINK:END] gründlich auf. Damit ist es nicht nur für Programmierer, sondern auch für Web-Designer und Grafiker interessant. Die völlig neu entwickelte Reinkarnation von CVS kann nun auch Binärdateien versionieren, Dateien unter Beibehaltung der Vorgeschichte umbenennen, besitzt atomare commits (für die CVS-user unter uns :-)) und stellt gleich diverse Schnittstellen für die Verwaltung über Netzwerke zur Verfügung. So gibt es ein WebDAV-Modul für Apache. Aber auch grafische Clients sind in der Mache. Hierzu gehören [LINK:START:352]RapidSVN[LINK:END], [LINK:START:351]TortoiseSVN[LINK:END] und einige andere.

Dies sind aber nicht die einzigen Gründe, warum Subversion so gut von den Entwicklern angenommen wird. Ohne jede grafische Oberfläche fühlt es sich erstmal an wie CVS, weil viele Kommandos und Optionen sich ähneln. Darüber hinaus ist es für etliche verschiedene Betriebssysteme verfügbar, darunter auch Windows, Linux, Mac OS X und Solaris. Ich werde hier eine vergleichsweise einfache Konfiguration des Servers vorstellen, der über SSH aufgerufen wird.

Installation auf Client und Server

Auf der [LINK:START:349]Downloadseite[LINK:END] findet man passende Programmpakete für eine Vielzahl gängiger Betriebssysteme in den jeweils dafür vorgesehenen Formaten. Sie enthalten sowohl die Server-, als auch die Client-Komponenten, weshalb die Pakete auf beiden Seiten installiert werden. RPM-Pakete sind dort ebenso zu finden, wie auch DEBs und die Pogrammquellen. Wer Debian sarge benutzt, dem reicht ein einfaches

apt-get install subversion

Wer noch woody auf der Platte hat, der trägt zunächst die Zeile

deb http://people.debian.org/~adconrad woody subversion

in die Datei /etc/apt/sources.list ein und macht ein

apt-get update

um dann subversion mit dem obigen Befehl zu installieren. Danach kann man die Zeile wieder aus der Datei löschen.

Bei allen anderen Distributionen dürfte die Installation nicht viel schwieriger sein.

Repository anlegen

Das Repository ist der Platz auf der Festplatte des Servers, wo die verschiedenen Versionsstände protokolliert und abgespeichert werden. Anstatt ständig neue Verzeichnisse mit merkwürdigen Versionsnummern anzulegen, reicht es bei einer Versionsverwaltung mit subversion wie auch mit CVS, regelmäßige Backups vom Repository anzulegen. Damit hat man auch für den Fall eines Hardwarefehlers vorgesorgt und sämtliche bisherigen Versionsstände gesichert. Zum Erstellen eines subversion Repository legt man erstmal an einer ausgewählten Stelle ein passendes Verzeichnis an.

mkdir /path/svn

Dann sorgt man dafür, dass in dieses Verzeichnis alle notwendigen Dinge reinkommen, die man für ein subversion Repository so braucht.

svnadmin create /path/svn/

Da in unserem Fall die Zugriffskontrolle ganz und gar über das Betriebssystem laufen soll, muss man dafür sorgen, dass nur ausgewählte Benutzer Zugriff auf das Repository haben. Als root legt man also eine entsprechende Benutzergruppe an und setzt die Attribute in diesem Verzeichnis angemessen:

addgroup subversion            # Benutzergruppe anlegen
chgrp -R subversion /path/svn/ # Gruppe subversion für alle Dateien setzen 
chmod -R o-rwx /path/svn/      # Alle anderen dürfen nix 
chmod -R g+rw /path/svn/       # Gruppenmitglieder dürfen auch schreiben
chmod g+s /path/svn/db         # Sicher stellen, dass Logfiles
			       # geschrieben werden können. 

Mit dem Befehl

adduser BNutzer subversion

wird der Benutzer "BNutzer" der Gruppe subversion hinzugefügt. So, nun muss man noch die Datei /path/svn/conf/svnserve.conf editieren. Wichtig sind die Zeilen:

[general]
anon-access = none 
auth-access = write
realm = TestRepos

Wobei "TestRepos" ein eindeutiger Name für dieses Repository ist. Damit kann man prinzipiell mehrere Repositories nebeneinander haben, wenn man verschiedene Namen vergibt. Die Zeile "anon-access = none" bedeutet, dass kein anonymer Zugriff erlaubt ist. Man könnte aber auch einen anonymen Lesezugriff erlauben, indem man "read" statt none verwendet. Da aber in unserem Fall die Authentifizierung über die SSH läuft, sollte es sowieso keine anonymen User geben. :-) Die nachfolgende Zeile legt entsprechend fest, dass autorisierte Benutzer lesen und schreiben dürfen.

Konfiguration des Server-Dienstes

Nun will man ja vielleicht nicht immer nur öffentlich zugängliche Subversion Server belästigen, sondern auch mal eigene Projekte auf einem eigenen Server lagern. Dafür muss man den Serverdienst für Subversion einrichten. Dieser bietet von Haus aus einen Tunnel-Modus, so dass dieser über eine SSH Verbindung genutzt werden kann. Die Vorteile liegen auf der Hand: Man muss nicht wirklich viel konfigurieren und auch die paranoiden unter der Admins freuen sich, weil man auf keinem Rechner ein neues Loch in die Firewall bohren muss. Allerdings macht das nur in Umgebungen Sinn, wo die betroffenen Benutzer sowieso einen SSH Zugang haben oder alle einen bekommen sollen. Um die SSH zum Laufen zu bekommen, muss man im Wesentlichen nur den SSH Dämon installieren, die Datei /etc/ssh/sshd_config (bei Debian) anpassen (man sshd_config) und den Dienst starten. Ich schlage spontan vor, den Zugriff der Benutzer in der Datei /etc/ssh/sshd_config mit der Option

AllowGroups subversion

zu beschränken. Damit die verschiedenen Benutzer sich nicht gegenseitig versehentlich aussperren, also die Dateiattribute so setzen, dass andere nicht mehr darauf zugreifen können, muss man für eine einheitliche umask sorgen. Mit der umask bzw. dem gleichnamigen Befehl stellt man die standardmäßig verwendeten Dateirechte ein, mit denen der Anwender Dateien anlegt und bearbeitet. Dies kann man erledigen, indem man ein wrapper Script

#!/bin/bash
umask 002
/usr/bin/svnserv $* 

mit dem Namen "svnserve" in das Verzeichnis legt, welches bei

which svnserve

ausgegeben wird und dafür das ursprüngliche Serverprogramm in svnserv umbenennt. Der Wert 007 statt 002 könnte auch ok sein. Dann wird allen anderen Systembenutzern des Servers der Einblick ins Repository untersagt. Empfohlen wird aber 002 als umask.

Projekt anlegen und einschleusen

Nun wird wieder am Client-Rechner geschraubt. Funktioniert der Zugang über SSH, dann braucht man nur noch ein Projekt. Ich lege hier mal ein Beispiel-Projekt in einem leeren Verzeichnis an, wie es auch in dem Subversion [LINK:START:350]Online-Buch[LINK:END] empfohlen wird:

mkdir Projekt
mkdir Projekt/trunk
mkdir Projekt/branches
mkdir Projekt/tags

In das Verzeichnis trunk (engl. Stamm) kommen die primären Projektdateien rein. Dann braucht es nur noch ein passendes Kommando

svn import Projekt svn+ssh://rechner.domain/path/svn/Projekt -m "Beschreibung der Änderungen"

und schon werden die Daten hochgeladen. Mit

svn co svn+ssh://rechner.domain/path/svn/Projekt

kann man einen checkout wie bei CVS durchführen. Da die exakte Beschreibung aller möglichen Kommandos von Subversion den Rahmen sprengen würde, verweise ich an dieser Stelle auf das besagte [LINK:START:350]Online-Buch[LINK:END] und die beiden Kommandos

svn help
svnadmin help

mit denen man etwas mehr über die Optionen der Werkzeuge erfährt. Wem das alles zu doof ist, der kann sich auch gern eines der grafischen Programme installieren. Allerdings tut es immer gut, wenn man im Zweifelsfall auch ohne diese auskommt. In diesem Sinne, viel Spaß beim Versionskontrollieren!

Artikelbewertung: 
4
Average: 4 (1 vote)
War dieser Artikel hilfreich?