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 „External 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–Zusammenfassen-Lösung“ erörtert, verschwindeten die meisten dieser Probleme vollständig, wenn Harry und Sallys Kommunikation perfekt wäre.[19] Aus der Tatsache, dass das eigene Versionskontrollsystem 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 Versionskontrollsysteme 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 [20] (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.
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
URL: http://svn.example.com/repos/project/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: Übertragen schlug fehl (Details folgen): svn: Der Server hat einen unerwarteten Rückgabewert (423 Locked) in Antwort auf die " Anfrage DELETE für »/repos/project/!svn/wrk/64bad3a9-96f9-0310-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-Konfigurationsbereich“).
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.
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 --show-updates
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 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.
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: »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: Sperrfreigabe 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: Sperranforderung gescheitert: 423 Locked (http://svn.example.com) $ 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
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.
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 --show-updates
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
übergeben, 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 irgend etwas 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: "Sperranforderung gescheitert: 423 Locked (http://svn.example.com) $ 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]](images/tip.png)
|
Tipp |
|---|---|
|
Es sei Benutzern und Administratoren gleichermaßen
empfohlen, die Eigenschaft |
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 Übergabe 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.[21]