| Version 20 (modified by , 15 years ago) ( diff ) |
|---|
Verwalten der Subversion-Repositories
Der paedml-Rechner dient als unser Subversion-Host. Momentan verwenden wir als Zugriffsmethode "svn über ssh-Tunnel" (siehe unten).
Unser Repository heißt keplertools. Es enthält zur Zeit die Unterprojekte
Clients
Jeder Nutzer, der sich per ssh am paedml-Rechner einloggen kann, kann Arbeitskopien des Repositories auschecken.
Der Zugriff wird besonders angenehm, wenn der Nutzer seinen ssh-Schlüssel hinterlegt, so dass er sich über den ssh-agent einloggen kann (=Passphraseeingabe nur einmal nötig, dann jeder weitere Zugriff ohne Passwort/Passphrase).
Zum Umgang mit der Arbeitskopie siehe Subversion-Manual.
Auschecken des kompletten Repositories
- Checkout von innerhalb des Kepler-Netzwerkes:
svn checkout svn+ssh://paedml.kg-fds.de/srv/svn/keplertools
- Checkout von außen:
export SVN_SSH="ssh -p 2222" svn checkout svn+ssh://paedml.kg-fds.de/srv/svn/keplertools
Auschecken eines Unterprojektes
- Checkout von innerhalb des Kepler-Netzwerkes:
svn checkout svn+ssh://paedml.kg-fds.de/srv/svn/keplertools/<project>/trunk <project>
- Checkout von außen:
export SVN_SSH="ssh -p 2222" svn checkout svn+ssh://paedml.kg-fds.de/srv/svn/keplertools/<project>/trunk <project>
Server
Physikalischer Speicherort
/srv/svn/<repos> (z.B. /srv/svn/keplertools)
Orientiert am File System Hierarchy Standard (FHS), dem Debian folgt.
Einrichten eines neuen Repositories
svnadmin create /srv/svn/<repos>
Zugriffsmethode
Subversion erlaubt verschiedene Server-Szenarien. Für uns kommen zwei davon in Frage:
- svn über ssh-Tunnel
- svn über Apache
Beide Varianten wären sinnvoll, weil
- alle potentiellen Nutzer einen vollständigen Systemaccount besitzen, sich also ssh-Schlüssel anlegen und sich dann über ssh einloogen können.
- der Apache V2 bereits gut läuft, mitsamt LDAP-Authentifizierung, und nur konfiguriert werden muss.
Beide Methoden haben Vor- und Nachteile, besonders hervorzuheben:
- svn über ssh-Tunnel hat potentiell Probleme mit den Nutzerrechten beim Schreiben auf das svn-Repository. Die lassen sich aber durch ein gewissenhaftes Rechtedesign lösen.
- Apache als Server ist äußerst flexibel (wobei wir die Flexibilität auf absehbare Zeit nicht benötigen), erzeugt bei den Zugriffen aber erheblich mehr Systemlast (=langsamer)
Das Subversion-Manual ist eine hervorragende Dokumentation zu allen diesen Fragen.
Wir müssen eine Entscheidung treffen, welches Szenario wir anwenden wollen. Ehrlichgesagt, bei unserem zu erwartenden Traffic (zwei aktive User und eine handvoll Dateien) ist der Systemaufwand vernachlässigbar.
Zur Zeit verwenden wir die Methode 1 (svn über ssh-Tunnel).
svn über ssh-Tunnel
Dieser Abschnitt beschreibt die notwendigen Einrichtungsschritte für Zugriff über das svn+ssh-Protokoll.
Bei dieser Zugriffsmethode greift jeder Nutzer unter seinem eigenen Namen auf das Repository zu. (Andere Szenarien, wie ein geteilter Account für mehrere Nutzer, siehe Svn-Manual.)
Um Probleme mit Schreibrechten zu lösen, sollten alle Nutzer, die auf das Repository zugreifen, in einer gemeinsamen Unix-Gruppe sein. Bei uns habe ich dazu die Gruppe svn eingerichtet.
addgroup --system svn
Für jeden Nutzer ausführen:
adduser <username> svn
Das gesamte Repository muss der Gruppe svn gehören:
chgrp --recursive svn /srv/svn/<repos>
Alle Verzeichnisse im Repository sollten das setgid-Bit gesetzt haben:
find /srv/svn/<repos> -type d -exec chmod g+s \{} +
Nutzerabhängige Konfiguration
- Checkout von innerhalb des Kepler-Netzwerkes:
svn checkout svn+ssh://paedml.kg-fds.de/srv/svn/<repos>
- Checkout von außen:
export SVN_SSH="ssh -p 2222" svn checkout svn+ssh://paedml.kg-fds.de/srv/svn/<repos>
- Die Nutzer müssen "vernünftige"
umasks haben (Schreib- und Lesezugriffe für Gruppe nicht verbieten!) - Für die Nutzer wird der Zugriff besonders angenehm, wenn sie ihren ssh-Schlüssel hinterlegen, so dass sie sich über den ssh-agent einloggen können (=Passphraseeingabe nur einmal nötig, dann jeder weitere Zugriff ohne Passwort/Passphrase).
svn über Apache
(details hierhier)
Svn und Trac
Trac unterstützt von Haus aus die Integration eines lokalen svn-Repositories. Damit das richtig läuft, müssen lediglich zwei einfache Hooks angelegt werden. Das ist hier gut beschrieben: TracRepositoryAdmin.
- Problem
- Die Hooks werden vom svn-User ausgeführt und brauchen Schreibberechtigung auf dem Trac-Environment. Das ist in unserem svn-über-ssh-Szenario derzeit nicht gegeben. Unser Trac läuft daher zur Zeit mit der alten
repository_sync_per_request-Option. Das sollte geändert werden und die Hooks eingerichtet werden, sobald Trac von Apache verteilt wird (#41). Näheres unter TracRepositoryAdmin.
