Download Name - Version Control with Subversion

Fortgeschrittene Themen
besitzen sie ein paar Einschränkungen. Änderungslisten sind Artefakte einer bestimmten Arbeitskopie, was bedeutet, dass
Änderungslisten-Zuweisungen nicht an das Projektarchiv weitergegeben und auch anderweitig nicht gemeinsam von anderen
Benutzern verwendet werden können. Änderungslisten lassen sich nur Dateien zuordnen – momentan unterstützt Subversion
nicht die Verwendung von Änderungslisten für Verzeichnisse. Schließlich können Sie einer gegebenen Datei der Arbeitskopie
höchstens eine Änderungsliste zuweisen. Hier passen die Analogien der Blog-Posts-Kategorien oder der Foto-Tags nicht mehr
– sollte es notwendig sein, eine Datei mehreren Änderungslisten zuzuweisen, haben Sie Pech.
Das Netzwerkmodell
Manchmal müssen Sie verstehen, wie Ihr Subversion-Client mit seinem Server kommuniziert. Die Netzwerkschicht von
Subversion ist abstrahiert, was bedeutet, dass die Clients von Subversion das gleiche allgemeine Verhalten an den Tag legen,
egal mit welcher Art von Server sie zusammenarbeiten. Ob sie im HTTP-Protokoll (http://) mit dem Apache HTTP-Server
oder im maßgeschneiderten Subversion Protokoll (svn://) mit svnserve sprechen, das grundlegende Netzwerkmodell ist das
selbe. In diesem Abschnitt werden wir die Grundlagen dieses Netzwerkmodells erläutern, auch wie Subversion die
Authentifizierung und die Autorisierung handhabt.
Anfragen und Antworten
Den größten Teil seiner Zeit verbringt der Subversion-Client mit der Verwaltung von Arbeitskopien. Wenn er jedoch
Informationen von einem entfernten Projektarchiv benötigt, stellt er eine Anfrage über das Netz, und der Server erwiedert mit
einer passenden Antwort. Die Details des Netzwerkprotokolls sind dem Benutzer verborgen – der Client versucht, auf einen
URL zuzugreifen, und abhänging vom URL-Schema wird ein bestimmtes Protokoll verwendet, um mit dem Server
Verbindung aufzunehmen (siehe Anmerkung Projektarchiv-URLs).
Rufen Sie svn --version auf, um zu sehen, welche URL-Schemas und Protokolle versteht.
Wenn der Server-Prozess eine Anfrage eines Clients erhält, verlangt er häufig, dass der Client sich identifiziert. Er sendet eine
Authentisierungsaufforderung an den Client und der Client antwortet, indem er Zugangsdaten zurückschickt. Sobald die
Authentifizierung abgeschlossen ist, antwortet der Server mit den ursprünglich vom Client angefragten Informationen.
Beachten Sie, dass dieses System sich von solchen wie CVS unterscheidet, bei denen der Client von sich aus dem Server
Zugangsdaten anbietet („sich anmeldet“), bevor überhaupt eine Anfrage erfolgt. In Subversion werden die Zugangsdaten vom
Server „eingezogen“, indem der Client zum passenden Zeitpunkt aufgefordert wird, und nicht indem der Client sie „abliefert“.
Das macht gewisse Operationen eleganter. Wenn ein Server beispielsweise so konfiguriert ist, dass jedem auf der Welt erlaubt
ist, ein Projektarchiv zu lesen, wird der Server niemals eine Authentisierungsaufforderung ausgeben, wenn ein Client svn
checkout versucht.
Falls die einzelnen Netzwerkanfragen des Clients zur Erstellung einer neuen Revision im Projektarchiv führen (z.B. svn
commit), verwendet Subversion den mit diesen Anfragen verknüpften authentifizierten Benutzernamen als Autor der Revision.
Das bedeutet, dass der Name des authentifizierten Benutzers als Wert der Eigenschaft svn:author der neuen Revision
zugewiesen wird (siehe „Subversion-Eigenschaften“). Falls der Client nicht authentifiziert wurde (d.h., falls der Server niemals
eine Authentisierungsaufforderung ausgegeben hat), bleibt die Revisionseigenschaft svn:author leer.
Zwischenspeicherung der Client-Zugangsdaten
Viele Server sind so konfiguriert, dass sie vor jeder Anfrage eine Authentisierung benötigen. Für Benutzer wäre es sehr lästig,
wenn sie jedes Mal das Passwort eingeben müssten. Glücklicherweise hat der Subversion-Client hierfür eine Abhilfe: ein
eingebautes System zum Zwischenspeichern der Zugangsdaten auf Platte. Standardmäßig legt der Kommandozeilen-Client die
Zugangsdaten immer im privaten Laufzeitkonfigurationsbereich des Benutzers ab (~/.subversion/auth/ auf Unixähnlichen Systemen oder %APPDATA%/Subversion/auth/ unter Windows; siehe „Laufzeit-Konfigurationsbereich“ für
Details zum Laufzeitkonfigurationssystem), wenn er erfolgreich auf die Authentisierungsanfrage des Servers antwortet. Die
gültigen Zugangsdaten werden auf Platte zwischengespeichert und mit einer Kombination aus dem Rechnernamen des Servers,
dem Port und dem Anmeldebereich referenziert.
Wenn der Client eine Authentisierungsaufforderung empfängt, schaut er zunächst nach den passenden Zugangsdaten im Cache
des Benutzers auf Platte. Falls passend erscheinende Zugangsdaten nicht verfügbar sind oder die zwischengespeicherten
Zugangsdaten letzlich nicht für eine Authentisierung ausreichen sollten, wird der Client standardmäßig den Benutzer zur
Eingabe der notwendigen Informationen auffordern.
75