[[PageOutline]]

= Subversion-Repository =

--work in progress--


== Repository ==


=== Physikalischer Speicherort ===

`/srv/svn`

Orientiert am [http://proton.pathname.com/fhs/ File System Hierarchy Standard (FHS)], dem [http://www.debian.org/doc/debian-policy/ch-opersys.html Debian folgt].

- WikiPedia:Filesystem_Hierarchy_Standard
- [http://proton.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM Beschreibung von `/srv/`im FHS]



== Server ==

Subversion erlaubt verschiedene Server-Szenarien. Für uns kommen zwei davon in Frage:
1. svn über ssh-Tunnel
1. svn über Apache
Beide Varianten wären sinnvoll, weil
1. alle potentiellen Nutzer einen vollständigen Systemaccount besitzen, sich also ssh-Schlüssel anlegen und sich dann über ssh einloogen können.
1. der Apache V2 bereits gut läuft, mitsamt LDAP-Authentifizierung, und nur konfiguriert werden muss.

Beide Methoden haben Vor- und Natchteile, besonders hervorzuheben:

1. 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.
1. 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 zunächst eine Entscheifung treffen, welches Szenario wir anwenden wollen. Ehrlichgesagt, bei unserem zu erwartendem Traffic (zwei aktive User und eine handvoll Dateien) ist der Systemaufwand vernachlässigbar.

Ich erprobe zur Zeit beide Szenarien und werde mich kurzfristig (morgen) für eins entscheiden, dass wir dann erstmal verwenden.



=== Einrichten eines neuen Repositories ===

{{{
svnadmin create /srv/svn/<repos>
}}}

=== svn über ssh-Tunnel ===

Dieser Abschnitt beschreibt die notwendigen Einrichtunbgsschritte 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" `umask`s 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 (=Passworteingabe nur einmal nötig, dann jeder weitere Zugriff ohne Passwort).


=== 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.

== Extrerne Links ==

- trac:TracSubversion
- trac:RepositoryType