Sie haben gesehen, wie auf viele verschiedene Weisen auf ein Projektarchiv zugegriffen werden kann. Ist es aber möglich, oder sicher, wenn auf Ihr Projektarchiv gleichzeitig mit mehreren Methoden zugegriffen wird? Die Antwort lautet: ja, vorausgesetzt, sie handeln ein bisschen vorausschauend.

Diese Prozesse benötigen jederzeit Lese- und Schreibzugriff auf Ihr Projektarchiv:

Das häufigste Problem, in das Administratoren laufen, besteht im Eigentumsverhältnis und den Zugriffsrechten des Projektarchivs. Hat jeder Prozess (oder Anwender) aus der obigen Liste die Rechte, die dem Projektarchiv zugrunde liegenden Dateien zu lesen und zu schreiben? Unter der Annahme, dass Sie ein Unix-ähnliches Betriebssystem haben, mag ein einfacher Ansatz darin bestehen, jeden möglichen Anwender des Projektarchivs in eine neue Gruppe svn aufzunehmen und dieser Gruppe die Eigentumsrechte über das Projektarchiv zu geben. Aber auch das reicht nicht, da ein Prozess die Datenbankdateien unter Verwendung einer widrigen umask schreiben könnte, so dass anderen Anwendern der Zugriff verwehrt würde.

Nach dem Einrichten einer gemeinsamen Gruppe für Projektarchiv-Anwender besteht der nächste Schritt darin, jeden Prozess, der auf das Projektarchiv zugreift, zu zwingen, eine passende umask zu verwenden. Für Anwender, die direkt auf das Projektarchiv zugreifen, können Sie das Programm svn in ein Skript umwandeln, das zunächst umask 002 aufruft und dann das eigentliche Client-Programm svn startet. Ein ähnliches Skript können Sie für das Programm svnserve schreiben, und in das Startskript von Apache, apachectl, fügen Sie das Kommando umask 002 ein. Zum Beispiel:

$ cat /usr/bin/svn

#!/bin/sh

umask 002
/usr/bin/svn-real "$@"

Ein weiteres bekanntes Problem tritt häufig auf Unix-ähnlichen Systemen auf. Wenn Ihr Projektarchiv beispielsweise auf Berkeley-DB aufsetzt, werden gelegentlich neue Dateien angelegt, um die Aktivitäten zu protokollieren. Selbst wenn die Gruppe svn vollständiger Eigentümer des Projektarchivs ist, müssen diese neu erstellten Protokolldateien nicht notwendigerweise derselben Gruppe gehören, was weitere Zugriffsprobleme für Ihre Anwender nach sich zieht. Ein guter Behelf besteht darin, das Gruppen-SUID-Bit für das Verzeichnis db des Projektarchivs zu setzen, was dazu führt, das alle neu erstellten Protokolldateien derselben Gruppe gehören wie das Elternverzeichnis.

Sobald Sie diese Hürden genommen haben, sollten alle notwendigen Prozesse auf Ihr Projektarchiv zugreifen können. Es scheint vielleicht etwas chaotisch und kompliziert, doch die Probleme, die bei gemeinsamen Zugriff mehrerer Anwender auf gemeinsame Dateien entstehen, sind Klassiker, die sich oft nicht elegant lösen lassen.

Glücklicherweise werden die meisten Administratoren von Projektarchiven niemals eine solch komplexe Konfiguration benötigen. Anwender, die auf Projektarchive des Rechners zugreifen möchten, an dem sie sich angemeldet haben, sind nicht auf URLs der Form file:// beschränkt, sondern können den Apache-Server oder svnserve mit localhost als Server-Namen in deren http:// oder svn:// URL verwenden. Darüber hinaus wird das Betreiben mehrfacher Server-Prozesse für Ihr Projektarchiv Ihnen mehr Kopfschmerzen bereiten als nötig ist. Wir empfehlen, einen einzigen Server zu wählen, der Ihren Bedürfnissen am nächsten kommt und dabei zu bleiben!