Dieser Text befindet sich gegenwärtig in Bearbeitung, unterliegt ständigen Änderungen und kann dadurch nicht stets akkurat irgendeine freigegebene Version der Software Apache™ Subversion® beschreiben. Das Speichern dieser Seite als Lesezeichen oder andere auf diese Seite zu verweisen, ist keine so gute Idee. Besuchen Sie http://www.svnbook.com/, um stabile Versionen dieses Buchs zu erhalten.

Sperren

Das Kopieren-Ändern-Zusammenfassen-Modell von Subversion lebt und stirbt mit dessen Zusammenführungs-Algorithmen – besonders dann, wenn es um die Fähigkeit dieser Algorithmen geht, Konflikte aufzulösen, die durch die gleichzeitigen Änderungen mehrerer Benutzer an derselben Datei hervorgerufen worden sind. Subversion bringt von sich aus nur einen derartigen Algorithmus mit: ein Dreiwege-Vergleichs-Algorithmus, der über ausreichend Intelligenz verfügt, um Daten mit der Granularität einer einzelnen Textzeile zu bearbeiten. Subversion erlaubt Ihnen auch, seine Zusammenführungs-Operationen mit externen Werkzeugen zu ergänzen (wie in „Externes diff3“ und „Externes merge“ beschrieben), von denen manche die Arbeit besser erledigen könnten, indem sie vielleicht die Granularität eines Wortes oder eines einzelnen Buchstaben bieten. Allerdings ist all diesen Algorithmen gemein, dass sie im Allgemeinen nur auf Textdateien arbeiten. Wenn es um nichttextuelle Dateiformate geht, sieht es ziemlich übel aus. Und falls Sie kein Werkzeug finden, das mit dieser Art von Zusammenführungen zurechtkommt, wirft das Kopieren-Ändern-Zusammenfassen-Modell Probleme für Sie auf.

Betrachten wir einmal ein Beispiel aus dem echten Leben, an dem dieses Modell scheitert. Harry und Sally sind Grafikdesigner und arbeiten am selben Projekt, ein bisschen Werbematerial für einen Automechaniker. Das Design für ein bestimmtes Plakat dreht sich um ein Bild, das ein reparaturbedürftiges Auto zeigt und in einer PNG-Datei abgelegt ist. Der Entwurf für das Plakat ist beinahe fertig, und sowohl Harry als auch Sally sind mit der Wahl des Fotos mit dem beschädigten Auto zufrieden – ein babyblauer 1967er Ford Mustang mit einer bedauerlichen Delle im Kotflügel vorne links.

Nun gibt es eine, im Grafikdesign übliche, Planänderung, was dazu führt, dass es Bedenken hinsichtlich der Farbe des Wagens gibt. Also aktualisiert Sally ihre Arbeitskopie auf HEAD, startet ihre Fotobearbeitungs-Software und ändert das Bild, so dass das Auto nun kirschrot ist. Zwischenzeitlich denkt sich Harry, der sich heute besonders inspiriert fühlt, dass die Wirkung des Bildes verstärkt würde, wenn der Wagen so aussähe, als habe er einen heftigeren Aufprall verkraften müssen. Auch er aktualisiert auf HEAD und malt ein paar Risse auf die Windschutzscheibe. Er ist vor Sally fertig und überträgt das veränderte Bild, nachdem er die Früchte seines unbestreitbaren Talents bewundert hat. Kurz danach ist Sally mit der neuen Autolackierung fertig und versucht, ihre Änderungen zu übertragen. Aber Subversion lässt, wie erwartet, die Übertragung scheitern und teilt Sally mit, dass ihre Version des Bildes nun veraltet sei.

Hier fangen die Schwierigkeiten an. Falls Harry und Sally Änderungen an einer Textdatei machten, aktualisierte Sally einfach ihre Arbeitskopie und erhielt dabei Harrys Änderungen. Schlimmstenfalls hätten beide denselben Dateiabschnitt verändert, und Sally müsste den Konflikt manuell auflösen. Aber es sind keine Textdateien – es sind binäre Bilder. Während es einfach ist, das erwartete Ergebnis der Zusammenführung der Inhalte zu beschreiben, ist die Wahrscheinlichkeit ziemlich gering, dass es eine Software gibt, die über ausreichend Intelligenz verfügt, das Bild auf dem beide Änderungen basieren, die Änderungen von Harry und die Änderungen von Sally zu untersuchen, um anschließend das Bild eines verbeulten roten Mustangs mit gesprungener Windschutzscheibe auszugeben.

Natürlich wäre es glatter gelaufen, wenn Harry und Sally ihre Änderungen an dem Bild nacheinander gemacht hätten – wenn etwa Harry gewartet hätte und seinen Sprung in der Windschutzscheibe auf Sallys nun roten Wagen gezeichnet hätte, oder wenn Sally die Farbe eines Autos mit bereits gesprungener Windschutzscheibe geändert hätte. Wie in „Die Kopieren-Ändern-Zusammenführen-Lösung“ erörtert, verschwindeten die meisten dieser Probleme vollständig, wenn Harry und Sallys Kommunikation perfekt wäre.[29] Aus der Tatsache, dass das eigene Versions-Kontroll-System eine Kommunikationsform darstellt, folgt, dass es keine schlechte Sache wäre, wenn diese Software die Serialisierung von nicht parallel durchführbaren Änderungen ermöglichte. Hier ist der Zeitpunkt für die Subversion-Implementierung des Sperren-Ändern-Freigeben-Modells gekommen. Hier reden wir nun über das Sperren in Subversion, das in etwa den Reserved Checkouts anderer Versions-Kontroll-Systeme entspricht.

Letztendlich existiert der Sperrmechanismus von Subversion, um die Verschwendung von Aufwand und Zeit zu minimieren. Indem einem Benutzer erlaubt wird, programmatisch das Exklusivrecht zum Ändern einer Datei im Projektarchiv in Anspruch zu nehmen, kann dieser Benutzer sich ziemlich sicher sein, dass die von ihm aufgebrachte Energie für nicht zusammenführbare Änderungen nicht verschwendet war – die Übersendung seiner Änderungen wird erfolgreich sein. Da Subversion auch den anderen Benutzern mitteilt, dass für ein bestimmtes versioniertes Objekt die Serialisierung aktiviert wurde, können diese Benutzer vernünftigerweise erwarten, dass dieses Objekt gerade von jemand anderen geändert wird. Auch sie können dann die Verschwendung ihrer Zeit und Energie für nicht zusammenführbare Änderungen vermeiden, die dann schließlich wegen mangelnder Aktualität nicht übertragen werden könnten.

Wenn sich auf den Sperrmechanismus von Subversion bezogen wird, ist eigentlich die Rede von einer ziemlich facettenreichen Ansammlung von Verhaltensweisen, die die Fähigkeit beinhaltet, eine versionierte Datei zu sperren [30] (die exklusive Berechtigung zum Ändern der Datei in Anspruch zu nehmen), die Datei freizugeben (die exklusive Änderungsberechtigung abzugeben), Berichte zu liefern, welche Dateien von wem gesperrt sind, Dateien mit Vermerken zu versehen, die das Sperren vor dem Ändern dringend empfehlen usw. In diesem Abschnitt behandeln wir all diese Facetten des umfangreicheren Sperrmechanismus.

Anlegen von Sperren

Im Projektarchiv von Subversion ist eine Sperre ein Metadatum, das einem Benutzer das exklusive Recht zum Ändern einer Datei erteilt. Dieser Benutzer wird Sperreigner genannt. Jede Sperre hat auch eine eindeutige Identifikation, üblicherweise eine lange Zeichenkette, Sperrmarke genannt. Das Projektarchiv verwaltet Sperren, letztendlich übernimmt es das Anlegen, das Durchsetzten und das Entfernen derselben. Falls irgendeine Übertragungstransaktion versucht, eine gesperrte Datei zu ändern oder zu löschen (oder eins der Elternverzeichnisse der Datei zu löschen), verlangt das Projektarchiv zweierlei Informationen: dass der die Übertragung ausführende Client sich als der Eigner der Sperrmarke authentisiert, und dass die Sperrmarke im Zuge der Übertragung vorgelegt wird, um zu beweisen, dass der Client weiß, welche Sperre verwendet wird.

Um das Anlegen einer Sperre zu demonstrieren, gehen wir zurück zu unserem Beispiel mit mehreren Grafikdesignern, die an derselben binären Bilddatei arbeiten. Harry hat sich entschieden, ein JPEG-Bild zu ändern. Um andere Leute daran zu hindern, Änderungen an der Datei zu übertragen, während er sie ändert (und auch, um ihnen mitzuteilen, dass er gerade Änderungen vornimmt), sperrt er die Datei im Projektarchiv mit dem Befehl svn lock.

$ svn lock banana.jpg -m "Editing file for tomorrow's release."
»banana.jpg« gesperrt durch »harry«.
$

Das vorangegangene Beispiel zeigt eine Menge neuer Dinge. Beachten Sie zunächst, dass Harry die Option --message (-m) an svn lock übergeben hat. Ähnlich wie svn commit kann der Befehl svn lock Kommentare annehmen, entweder über --message (-m) oder --file (-F), um den Grund für die Dateisperre zu beschreiben. Im Gegensatz zu svn commit verlangt svn lock jedoch nicht nach einer Nachricht, indem es Ihren bevorzugten Texteditor aufruft. Sperrkommentare sind zwar optional, aber zur Unterstützung der Kommunikation empfohlen.

Zum Zweiten war der Sperrversuch erfolgreich. Das bedeutet, dass die Datei noch nicht gesperrt war, und Harry die letzte Version der Datei hatte. Falls Harrys Arbeitskopie der Datei nicht mehr aktuell gewesen wäre, hätte das Projektarchiv die Anfrage abgelehnt und Harry dazu gezwungen, svn update aufzurufen und den Sperrbefehl dann erneut zu versuchen. Der Sperrbefehl wäre ebenso fehlgeschlagen, falls die Datei bereits von jemand anderem gesperrt worden wäre.

Wie Sie sehen können, gibt der Befehl svn lock eine Bestätigung bei einer erfolgreichen Sperrung aus. An dieser Stelle wird die Tatsache, dass die Datei gesperrt ist, durch die Ausgabe der berichtenden Unterbefehle svn status und svn info offensichtlich.

$ svn status
     K  banana.jpg

$ svn info banana.jpg 
Pfad: banana.jpg
Name: banana.jpg
Working Copy Root Path: /home/harry/project
URL: http://svn.example.com/repos/project/banana.jpg
Relative URL: ^/banana.jpg
Basis des Projektarchivs: http://svn.example.com/repos/project
UUID des Projektarchivs: edb2f264-5ef2-0310-a47a-87b0ce17a8ec
Revision: 2198
Knotentyp: Datei
Plan: normal
Letzter Autor: frank
Letzte geänderte Rev: 1950
Letztes Änderungsdatum: 2006-03-15 12:43:04 -0600 (Wed, 15 Mar 2006)
Text zuletzt geändert: 2006-06-08 19:23:07 -0500 (Thu, 08 Jun 2006)
Eigenschaften zuletzt geändert: 2006-06-08 19:23:07 -0500 (Thu, 08 Jun 2006)
Prüfsumme: 3b110d3b10638f5d1f4fe0f436a5a2a5
Sperrmarke: opaquelocktoken:0c0f600b-88f9-0310-9e48-355b44d4a58e
Sperreigner: harry
Sperre erzeugt: 2006-06-14 17:20:31 -0500 (Wed, 14 Jun 2006)
Sperrkommentar (1 Zeile):
Editing file for tomorrow's release.

$

Aus der Tatsache, dass der Befehl svn info, der nicht das Projektarchiv kontaktiert, wenn er mit einem Pfad der Arbeitskopie aufgerufen wird, die Sperrmarke anzeigen kann, enthüllt eine wichtige Information über diese Marken: sie werden in der Arbeitskopie zwischengespeichert. Das Vorhandensein der Sperrmarke ist kritisch. Sie erteilt der Arbeitskopie die Berechtigung, die Sperrmarke später zu verwenden. Darüber hinaus zeigt der Befehl svn status ein K neben der Datei an (kurz für locKed, gesperrt), was darauf hinweist, dass die Sperrmarke vorhanden ist.

Da Harry nun banana.jpg gesperrt hat, kann Sally diese Datei weder ändern noch löschen:

$ svn delete banana.jpg
D         banana.jpg
$ svn commit -m "Delete useless file." 
Lösche         banana.jpg
svn: E175002: Übertragen schlug fehl (Details folgen):
svn: E175002: Der Server hat einen unerwarteten Rückgabewert (423 Locked) in
Antwort auf die Anfrage DELETE für »/repos/project/!svn/wrk/64bad3a9-96f9-031
0-818a-df4224ddc35d/banana.jpg« zurückgeliefert"
$

Harry aber kann seine Änderungen an der Datei übertragen, nachdem er das Gelb der Banane verbessert hat. Das funktioniert, da er sich als der Sperreigner authentisiert hat, und weil seine Arbeitskopie die korrekte Sperrmarke beinhaltet:

$ svn status
M    K  banana.jpg
$ svn commit -m "Make banana more yellow" 
Sende          banana.jpg
Übertrage Daten .
Revision 2201 übertragen.
$ svn status
$

Beachten Sie, dass nach Abschluss der Übertragung svn status anzeigt, dass die Sperrmarke nicht mehr in der Arbeitskopie vorhanden ist. Das ist das Standardverhalten von svn commit – es durchsucht die Arbeitskopie (oder die Liste von Zielobjekten, falls angegeben) nach lokalen Änderungen und sendet im Zuge der Übertragungstransaktion alle Sperrmarken denen es begegnet an den Server. Nach dem erfolgreichem Abschluss der Übertragung, sind alle erwähnten Sperren aufgehoben – sogar für Dateien, die nicht übertragen worden sind. Das soll Benutzer davon abschrecken, beim Sperren oder beim langen Halten von Sperren schludrig zu sein. Falls Harry wahllos 30 Dateien in einem Verzeichnis namens images sperrt, weil er sich nicht sicher ist, welche Dateien er ändern muss, dann aber nur vier dieser Dateien ändert, werden trotzdem alle 30 Sperren freigegeben, wenn er svn commit images aufruft.

Dieses Verhalten der automatischen Sperrfreigabe kann mit der Option --no-unlock von svn commit unterbunden werden. Diese Option wird am besten dann verwendet, wenn Sie Änderungen übertragen möchten, aber trotzdem weitere Änderungen planen und die Sperren deshalb beibehalten werden sollen. Sie können das auch zum Standardverhalten machen, indem Sie die Laufzeitoption no-unlock setzen (siehe „Laufzeit-Konfigurations-Bereich“).

Natürlich wird durch das Sperren einer Datei keine Verpflichtung eingegangen, eine Änderung übertragen zu müssen. Die Sperre kann jederzeit mit einem einfachen svn unlock freigegeben werden:

$ svn unlock banana.c 
»banana.c« freigegeben.

Entdecken von Sperren

Falls eine Übertragung aufgrund der Sperre von jemand anderen fehlschlägt, ist es ziemlich einfach, Informationen darüber zu erhalten. Die einfachste Möglichkeit ist, svn status -u aufzurufen:

$ svn status -u
M               23   bar.c
M    O          32   raisin.jpg
        *       72   foo.h 
Status bezogen auf Revision:     105
$

In diesem Beispiel kann Sally nicht nur sehen, dass ihre Kopie von foo.h nicht mehr aktuell ist, sondern auch, dass eine der zwei geänderten Dateien, die sie übertragen wollte, im Projektarchiv gesperrt ist. Das Symbol O steht für Other, was bedeutet, dass eine Sperre auf der Datei liegt, die von jemand anderen angelegt wurde. Wenn sie eine Übertragung versuchte, würde die Sperre auf raisin.jpg das verhindern. Sally fragt sich jetzt nur noch, wer die Sperre wann und warum angelegt hat. Auch hierzu liefert svn info die Antwort:

$ svn info ^/raisin.jpg 
Pfad: raisin.jpg
Name: raisin.jpg
URL: http://svn.example.com/repos/project/raisin.jpg
Relative URL: ^/raisin.jpg
Basis des Projektarchivs: http://svn.example.com/repos/project
UID des Projektarchivs: edb2f264-5ef2-0310-a47a-87b0ce17a8ec
Revision: 105
Knotentyp: Datei
Letzter Autor: sally
Letzte geänderte Rev: 32
Letztes Änderungsdatum: 2006-01-25 12:43:04 -0600 (Sun, 25 Jan 2006)
Sperrmarke: opaquelocktoken:fc2b4dee-98f9-0310-abf3-653ff3226e6b
Sperreigner: harry
Sperre erzeugt: 2006-02-16 13:29:18 -0500 (Thu, 16 Feb 2006)
Sperrkommentar (1 Zeile):
Need to make a quick tweak to this image.
$

Ebenso, wie Sie svn info zum Untersuchen von Objekten in der Arbeitskopie verwenden können, erlaubt es Ihnen, Objekte im Projektarchiv zu untersuchen. Falls das Hauptargument von svn info ein Pfad der Arbeitskopie ist, wird die gesamte zwischengespeicherte Information der Arbeitskopie angezeigt; die Erwähnung irgendeiner Sperre bedeutet, dass die Arbeitskopie eine Sperrmarke hält (falls eine Datei von einem anderen Benutzer oder in einer anderen Arbeitskopie gesperrt ist, zeigt svn info mit einem Pfad der Arbeitskopie keinerlei Informationen über Sperren an). Falls das Hauptargument zu svn info ein URL ist, spiegelt die Information die letzte Version eines Objektes im Projektarchiv wider, und die Erwähnung einer Sperre beschreibt die aktuelle Sperre auf dem Objekt.

In diesem konkreten Beispiel kann Sally sehen, dass Harry die Datei am 16. Februar gesperrt hat, um eine schnelle Optimierung zu machen. Da es nun Juni ist, vermutet sie, dass er wahrscheinlich die Sperre vergessen hat. Sie könnte Harry anrufen, um sich zu beschweren und ihn aufzufordern, die Datei freizugeben. Sollte er nicht erreichbar sein, könnte sie versuchen, selber die Freigabe zu erzwingen oder einen Administrator darum zu bitten.

Freigabeerzwingung und Stehlen von Sperren

Eine Sperre im Projektarchiv ist nicht heilig – in der Standardkonfiguration von Subversion können Sperren nicht nur durch die Personen freigegeben werden, die sie angelegt haben, sondern durch jeden. Falls jemand anderes als der ursprüngliche Erzeuger der Sperre diese zerstört, nennen wir das die Freigabe der Sperre erzwingen.

Vom Platz eines Administrators aus ist es einfach, eine Freigabe zu erzwingen. Die Programme svnlook und svnadmin können Sperren direkt aus dem Projektarchiv anzeigen sowie entfernen. (Weitere Informationen zu diesen Werkzeugen unter „Der Werkzeugkasten eines Administrators“.)

$ svnadmin lslocks /var/svn/repos 
Pfad: /project2/images/banana.jpg
UUID Marke: opaquelocktoken:c32b4d88-e8fb-2310-abb3-153ff1236923
Eigentümer: frank
Erstellt: 2006-06-15 13:29:18 -0500 (Thu, 15 Jun 2006)
Läuft ab: 
Kommentar (1 Zeile):
Still improving the yellow color.

Pfad: /project/raisin.jpg
UUID Marke: opaquelocktoken:fc2b4dee-98f9-0310-abf3-653ff3226e6b
Eigentümer: harry
Erstellt: 2006-02-16 13:29:18 -0500 (Thu, 16 Feb 2006)
Läuft ab: 
Kommentar (1 Zeile):
Need to make a quick tweak to this image.

$ svnadmin rmlocks /var/svn/repos /project/raisin.jpg 
Sperre für »/project/raisin.jpg« entfernt.
$

Die interessantere Option ist, es den Benutzern zu erlauben, gegenseitig über das Netz die Freigabe zu erzwingen. Um das zu machen, muss Sally dem Befehl svn unlock einfach ein --force mitgeben:

$ svn status -u
M               23   bar.c
M    O          32   raisin.jpg
        *       72   foo.h 
Status bezogen auf Revision:     105
$ svn unlock raisin.jpg 
svn: E195013: '»raisin.jpg« ist in dieser Arbeitskopie nicht gesperrt.
$ svn info raisin.jpg | grep ^URL
URL: http://svn.example.com/repos/project/raisin.jpg
$ svn unlock http://svn.example.com/repos/project/raisin.jpg 
svn: Warnung: W160039: USperrfreigabe gescheitert: 403 Forbidden (http://svn.example.com)
$ svn unlock --force http://svn.example.com/repos/project/raisin.jpg 
»raisin.jpg« freigegeben.
$

Sallys erster Versuch, die Sperre aufzuheben, schlug fehl, da sie svn unlock direkt in ihrer Arbeitskopie ausführte und keine Sperrmarke vorhanden war. Um die Sperre direkt aus dem Projektarchiv zu entfernen, muss sie svn unlock einen URL übergeben. Ihr erster Versuch, den URL zu entsperren, schlägt fehl, da sie sich nicht als der Sperreigner authentisieren kann (sie hat ja auch nicht die Sperrmarke). Wenn sie jedoch --force übergibt, werden die Authentisierungs- und Berechtigungsanforderungen ignoriert und die entfernte Freigabe wird erzwungen.

Es kann sein, dass das einfache Erzwingen einer Freigabe nicht ausreicht. Im aktuellen Beispiel könnte Sally nicht nur beabsichtigt haben, Harrys längst vergessene Sperre zu beseitigen, sondern die Datei für sich zu sperren. Sie kann das erreichen, indem sie svn unlock mit --force aufruft und direkt anschließend svn lock; hier besteht jedoch eine geringe Wahrscheinlichkeit, dass jemand anderes die Datei zwischen den beiden Befehlen sperren könnte. Einfacher ist es, die Sperre zu stehlen, was bedeutet, die Datei in einem atomaren Schritt freizugeben und wieder zu sperren. Um das zu tun, übergibt Sally die Option --force an svn lock:

$ svn lock raisin.jpg 
svn: Warnung: W160035: Pfad »/project/raisin.jpg« ist bereits vom Benutzer »ha
rry« im Dateisystem »/var/svn/repos/db« gesperrt
$ svn lock --force raisin.jpg 
»raisin.jpg« gesperrt durch »sally«.
$

Auf jeden Fall wird Harry eine Überraschung erleben, egal, ob die Freigabe erzwungen oder die Sperre gestohlen wurde. Die Arbeitskopie von Harry beinhaltet immer noch die ursprüngliche Sperrmarke, die dazugehörige Sperre gibt es jedoch nicht mehr. Die Sperrmarke wird als erloschen bezeichnet. Die durch die Sperrmarke repräsentierte Sperre wurde entweder durch eine Freigabeerzwingung zerstört (sie befindet sich nicht mehr im Projektarchiv) oder gestohlen (durch eine andere Sperre ersetzt). Egal wie, Harry kann es sehen, wenn er svn status auffordert, Kontakt zum Projektarchiv aufzunehmen:

$ svn status
     K  raisin.jpg
$ svn status -u
     B          32   raisin.jpg 
Status bezogen auf Revision:     105
$ svn update 
Updating ».«:
  B  raisin.jpg 
Aktualisiert zu Revision 105.
$ svn status
$

Falls die Freigabe erzwungen wurde, zeigt svn status --show-updates (-u) ein B-Symbol (Broken) neben der Datei an. Falls es eine neue Sperre an Stelle der alten gibt, wird ein T-Symbol (gestohlen) angezeigt. Zu guter Letzt entdeckt svn update irgendwelche erloschenen Sperrmarken und entfernt sie aus der Arbeitskopie.

Kommunikation über Sperren

Wir haben uns angesehen, wie svn lock und svn unlock verwendet werden können, um Sperren anzulegen, freizugeben und deren Freigabe zu erzwingen. Dies erfüllt den Zweck, den Zugriff zum Übergeben von Änderungen an einer Datei zu serialisieren. Aber wie sieht es mit dem größeren Problem aus, Zeitverschwendung zu vermeiden?

Nehmen wir beispielsweise an, dass Harry eine Bilddatei sperrt und mit deren Bearbeitung beginnt. Mittlerweile, weit entfernt, möchte Sally das Gleiche machen. Sie denkt nicht daran, svn status -u aufzurufen, so dass sie nicht mitbekommt, dass Harry die Datei bereits gesperrt hat. Sie verbringt Stunden mit der Bearbeitung der Datei, und beim Versuch, ihre Änderungen zu übertragen, stellt sie fest, dass die Datei entweder gesperrt oder nicht mehr aktuell ist. Wie auch immer – ihre Änderungen lassen sich nicht mit denen Harrys zusammenführen. Eine Person von beiden muss ihre Arbeit wegwerfen, und eine Menge Zeit ist verschwendet worden.

Die Lösung von Subversion für dieses Problem besteht in einem Mechanismus, der Benutzer daran erinnert, dass eine Datei vor dem Ändern gesperrt werden sollte. Es handelt sich um eine besondere Eigenschaft: svn:needs-lock. Wenn diese Eigenschaft einer Datei zugeordnet ist (egal mit welchem Wert), versucht Subversion mit Dateisystem-Zugriffsrechten, die Datei nur lesbar zu machen – natürlich nur dann, wenn der Benutzer die Datei nicht ausdrücklich gesperrt hat. Wenn eine Sperrmarke vorhanden ist (als ein Ergebnis eines Aufrufs von svn lock), wird die Datei schreib- und lesbar. Wird die Sperre freigegeben, wird die Datei wieder nur lesbar.

Die Theorie ist die, dass Sally sofort merkt, dass irgendetwas nicht stimmt, wenn sie die mit dieser Eigenschaft versehene Bilddatei zum Ändern öffnet: Viele Anwendungen benachrichtigen Benutzer sofort, wenn eine nur lesbare Datei zum Ändern geöffnet werden soll, und fast alle verhindern es, dass Änderungen an der Datei gespeichert werden. Das erinnert sie daran, die Datei vor dem Ändern zu sperren, wobei sie die bereits bestehende Sperre entdeckt:

$ /usr/local/bin/gimp raisin.jpg
gimp: error: file is read-only!
$ ls -l raisin.jpg
-r--r--r--   1 sally   sally   215589 Jun  8 19:23 raisin.jpg
$ svn lock raisin.jpg 
svn: Warnung: W160035: Pfad »/project/raisin.jpg« ist bereits vom Benutzer »ha
rry« im Dateisystem »/var/svn/repos/db« gesperrt
$ svn info http://svn.example.com/repos/project/raisin.jpg | grep Lock 
Sperrmarke: opaquelocktoken:fc2b4dee-98f9-0310-abf3-653ff3226e6b
Sperreigner: harry
Sperre erzeugt: 2006-06-08 07:29:18 -0500 (Thu, 08 June 2006)
Sperrkommentar (1 Zeile):
Making some tweaks.  Locking for the next two hours.
$
[Tipp] Tipp

Es sei Benutzern und Administratoren gleichermaßen empfohlen, die Eigenschaft svn:needs-lock an allen Dateien anzubringen, die nicht kontextabhängig zusammengeführt werden können. Dies ist die wichtigste Technik, um ein gutes Sperrverhalten zu bestärken und vergeudeten Aufwand zu vermeiden.

Beachten Sie, dass diese Eigenschaft ein Kommunikationswerkzeug darstellt, welches unabhängig vom Sperrsystem funktioniert. Mit anderen Worten: Jede Datei kann gesperrt werden, egal, ob diese Eigenschaft vorhanden ist oder nicht. Und andersherum bedeutet das Vorhandensein dieser Eigenschaft nicht, dass das Projektarchiv bei der Übertragung eine Sperre erforderlich macht.

Leider ist dieses System nicht unfehlbar. Es ist möglich, dass die Nur-Lesbar-Erinnerung nicht immer funktioniert, auch wenn eine Datei diese Eigenschaft besitzt. Manchmal benehmen sich Anwendungen daneben und kapern die nur lesbare Datei, indem sie dem Benutzer trotzdem stillschweigend das Ändern und Sichern gestatten. In dieser Situation kann Subversion nicht viel machen – letztendlich gibt es einfach keinen Ersatz für gute zwischenmenschliche Kommunikation.[31]



[29] Kommunikation wäre insofern auch keine schlechte Medizin für die gleichnamigen Harry und Sally aus Hollywood gewesen.

[30] Momentan erlaubt Subversion nicht das Sperren von Verzeichnissen.

[31] Vielleicht mit Ausnahme einer klassischen vulkanischen Gedankenvereinigung.