Subversion funktioniert im Allgemeinen am besten ohne Sperren, da es den in „Die Kopieren-Ändern-Zusammenführen-Lösung“ besprochenen Ansatz verfolgt. Es gibt jedoch einige Fälle, in denen es erforderlich ist, Dateien zu sperren.
Sie arbeiten mit „nicht zusammenführbaren“ Dateien, z. B. Grafiken. Wenn zwei Personen dieselbe Datei modifizieren, ist ein Zusammenführen nicht möglich, sodass einer der beiden seine Änderungen verlieren wird.
Ihre Firma hat bisher immer ein sperrendes Versionskontrollsystem eingesetzt und es gibt eine Management-Entscheidung, dass „Sperren das Beste“ ist.
Zunächst müssen Sie sicherstellen, dass Ihr Subversion-Server zumindest mit Version 1.2 arbeitet. Frühere Versionen unterstützen Sperren überhaupt nicht. Wenn Sie ausschließlich den file://-Zugriff nutzen, müssen nur Ihre Clients aktualisiert werden.
Die drei Bedeutungen von „Sperre“
In diesem Abschnitt und fast überall in diesem Buch beschreiben die Worte „Sperre“ und „Sperren“ einen Mechanismus zum wechselseitigen Ausschluss zwischen Benutzern, um Konflikte zu vermeiden. Leider gibt es zwei andere Arten von „Sperren“, mit denen Subversion und dieses Buch sich manchmal befassen müssen.
Die zweite Bedeutung bezieht sich auf gesperrte Arbeitskopien, die intern von Subversion verwendet werden, um Kollisionen zwischen mehreren Subversion-Clients zu verhindern, die auf dieselbe Arbeitskopie zugreifen. Diese Sperren können auftreten, wenn z. B. ein Befehl wie „Aktualisieren/Übertragen/...“ aufgrund eines Fehlers unterbrochen wurde. Sie entfernen die Sperren, indem Sie den „Aufräumen“-Befehl auf der Arbeitskopie ausführen, wie in „Bereinigen“ beschrieben.
Drittens können Dateien oder Ordner gesperrt werden, wenn sie von einem anderen Prozess verwendet werden. Wenn Sie z. B. ein Dokument geöffnet haben, kann diese Datei gesperrt sein und durch TortoiseSVN nicht verändert werden.
Im Allgemeinen brauchen Sie den anderen Sperren solange keine Beachtung zu schenken, wie alles funktioniert und Sie sich nicht darum kümmern müssen. In diesem Buch hat „Sperre“ stets die erste Bedeutung, es sei denn, es ist vom Kontext her klar oder es wird explizit darauf hingewiesen.
In der Grundeinstellung sind keine Objekte gesperrt und jeder, der die entsprechende Berechtigung hat, kann seine Änderungen in das Projektarchiv übertragen. Andere werden Ihre Arbeitskopien regelmäßig aktualisieren und Änderungen im Projektarchiv werden mit den lokalen Änderungen zusammengeführt.
Wenn Sie für eine Datei Eine Sperre holen, können nur Sie Änderungen an dieser Datei übertragen. Übertragungen von anderen werden solange verhindert, bis Sie die Sperre wieder freigeben. Eine gesperrte Datei kann in keiner Weise im Projektarchiv verändert, umbenannt oder gelöscht werden. Dies ist nur dem Eigner der Sperre möglich.
Wichtig
Eine Sperre ist nicht an einen bestimmten Benutzer, sondern an eine bestimmte Arbeitskopie dieses Benutzers gebunden. Eine Sperre in einer Arbeitskopie hindert denselben Anwender daran, die gesperrte Datei von einer anderen Arbeitskopie aus einzuchecken.
Stellen Sie sich vor, dass John eine Arbeitskopie auf seinem Bürocomputer hat. Dort beginnt er ein Bild zu bearbeiten und holt sich deshalb eine Sperre für die Datei. Als er nach Hause geht, ist er noch nicht fertig und gibt deswegen die Sperre nicht frei. Daheim hat John noch eine Arbeitskopie und beschließt, noch ein wenig an dem Bild weiterzuarbeiten. Aber er kann das Bild nicht bearbeiten oder einchecken, weil die Dateisperre zur Arbeitskopie in seinem Büro gehört.
Andere Anwender werden nicht unbedingt wissen, dass Sie eine Datei gesperrt haben. Wenn sie nicht regelmäßig den Sperrstatus überprüfen, werden sie es frühestens merken, wenn ihre Übertragung fehlschlägt, was in den meisten Fällen nicht sehr nützlich ist. Damit es einfacher ist, Sperren zu verwalten, gibt es die neue Eigenschaft svn:needs-lock von Subversion. Wenn diese Eigenschaft (auf einen beliebigen Wert) gesetzt ist, wird beim Auschecken oder Aktualisieren die Datei in der Arbeitskopie mit einem Schreibschutz versehen, es sei denn, die Arbeitskopie besitzt die Sperre für die Datei. Dies dient als Warnung, dass Sie die Datei nicht bearbeiten sollen, bevor Sie nicht die Sperre für die Datei besitzen. Dateien unter Versionskontrolle, die mit Schreibschutz versehen sind, erhalten von TortoiseSVN ein überlagertes Symbol, das anzeigt, dass Sie erst eine Sperre holen müssen, bevor Sie die Datei bearbeiten.
Sperren gehören sowohl zu einer Arbeitskopie als auch zu einer Person. Wenn Sie mehrere Arbeitskopien desselben Projekts (bei der Arbeit, daheim) haben, können Sie eine Datei nur in einer dieser Arbeitskopien sperren.
Wenn einer Ihrer Kollegen eine Datei sperrt und in Urlaub geht, ohne die Sperre vorher freizugeben, was dann? Subversion bietet Ihnen eine Möglichkeit, Sperren auszuhebeln. Eine Sperre freizugeben, die jemand anders besitzt, wird auch Sperre aufbrechen genannt. Sich eine Sperre zu holen, die jemand anders besitzt, wird auch Sperre stehlen genannt. Selbstverständlich sollten Sie dies nicht leichtfertig tun, wenn Sie sich weiterhin mit Ihren Kollegen gut stellen wollen.
Sperren werden im Projektarchiv verwaltet und eine Sperrmarke wird zusätzlich in Ihrer Arbeitskopie angelegt. Wenn es einen Unterschied zwischen diesen Werte gibt, weil zum Beispiel jemand eine Sperre aufgebrochen hat, wird die lokale Sperrmarke ungültig. Der Sperrstatus im Projektarchiv ist stets maßgeblich.
Markieren Sie die Datei(en) in Ihrer Arbeitskopie, für die Sie eine Sperre erhalten möchten und wählen Sie → .
Ein Dialog erscheint, in dem Sie einen Sperrkommentar eingeben können, damit andere wissen, warum Sie die Datei für sich reservieren. Der Kommentar ist optional und wird derzeit nur bei svnserve-basierten Projektarchiven genutzt. Wenn (und nur wenn) Sie eine Sperre von jemand anderem stehlen wollen, aktivieren Sie die Option Sperren stehlen, bevor Sie auf klicken.
Sie können die Projekteigenschaft tsvn:logtemplatelock setzen, um den Anwendern eine Schablone zum Erfassen der Sperrmeldung anzubieten. Lesen Sie in „Projekt-Einstellungen“ nach, wie Eigenschaften gesetzt werden.
Wenn Sie einen Ordner markieren und → aufrufen, wird der Sperr-Dialog mit jeder Datei in jedem zum Sperren ausgewählten Unterordner geöffnet. Wenn Sie wirklich eine ganze Ordnerstruktur sperren wollen, ist das der richtige Weg, es zu erreichen. Sie können sich damit allerdings bei Ihren Kollegen sehr unbeliebt machen, wenn Sie diese aus dem gesamten Projekt aussperren ...
Um sicherzustellen, dass Sie nicht vergessen, Sperren freizugeben, werden gesperrte Dateien im Übertragen-Dialog angezeigt und sind standardmäßig gewählt. Wenn Sie die Übertragung durchführen, werden die Sperren der markierten Dateien freigegeben, auch wenn die Dateien selbst sich nicht geändert haben. Wenn Sie die Dateisperren nicht freigeben wollen, können Sie die entsprechenden Dateien abwählen, vorausgesetzt, dass sie nicht modifiziert sind. Wenn Sie die Sperre für veränderte Dateien behalten wollen, müssen Sie vor der Übertragung die Option Sperren behalten aktivieren.
Um eine Sperre von Hand freizugeben, markieren Sie die gewünschten Datei(en) in Ihrer Arbeitskopie und wählen Sie → . TortoiseSVN wird das Projektarchiv kontaktieren und die Sperren dort freigeben. Sie können diesen Befehl auch für einen Ordner aufrufen, um alle Sperren rekursiv freizugeben.
Um zu sehen, welche Sperren Sie oder andere Personen besitzen, können Sie → aufrufen. Lokale Sperren werden sofort angezeigt. Damit Sie sehen können, welche Sperren von anderen gehalten werden und um festzustellen, ob Ihre Sperren aufgebrochen oder gestohlen wurden, müssen Sie wählen.
Aus dem Kontextmenü dieses Dialogs heraus können Sie Sperren holen oder freigeben und auch Sperren von anderen stehlen oder aufbrechen.
Vermeiden Sie es, Sperren aufzubrechen oder zu stehlen
Wenn Sie die Sperre eines Kollegen stehlen oder aufbrechen, ohne ihm dies mitzuteilen, können Sie doppelte Arbeit verursachen. Wenn Sie mit nicht zusammenführbaren Dateien arbeiten und die Sperre eines anderen Benutzers stehlen, kann dieser Ihre Daten überschreiben, sobald Sie die Sperre freigeben. Subversion verliert zwar keine Daten, aber Sie haben den Schutz bei der Zusammenarbeit verloren, den Ihnen die Sperre gegeben hat.
Wie bereits erwähnt, ist der einfachste Weg, Sperren zu verwenden, die Eigenschaft svn:needs-lock auf Dateien zu setzen. Lesen Sie „Projekt-Einstellungen“, um zu erfahren, wie man Eigenschaften setzt. Dateien mit dieser Eigenschaft werden beim Aktualisieren und Auschecken stets mit einem Schreibschutz versehen, wenn die Arbeitskopie keine Sperre für die Datei besitzt.
Als Erinnerung zeigt TortoiseSVN dieses Symbol dafür an.
Wenn Sie ein Entwicklungsverfahren nutzen, das stets Dateisperren erfordert, ist es einfacher, die Subversion-Eigenschaft auto-props zu nutzen, um die Dateieigenschaften automatisch zu setzen, sobald Sie Dateien zum Projektarchiv hinzufügen. Lesen Sie „Eigenschaften automatisch setzen“ für weitere Information.
Wenn Sie ein neues Projektarchiv mit Subversion 1.2 anlegen, werden vier Schablonen für Aktionsskripte im hooks-Verzeichnis des Projektarchivs angelegt. Diese Aktionsskripte werden aufgerufen, bevor und nachdem eine Sperre geholt bzw. freigegeben wird.
Es ist eine gute Idee, ein post-lock- und ein post-unlock-Aktionsskript auf dem Server zu installieren, die eine Benachrichtigungs-E-Mail verschicken. Mit solch einem Skript können alle betroffenen Personen darüber informiert werden, wenn eine Datei gesperrt wurde. Sie finden das Beispielskript hooks/post-lock.tmpl in Ihrem Projektarchiv.
Vielleicht möchten Sie mit Aktionsskripten auch verhindern, dass jemand Sperren stiehlt oder aufbricht oder Sie möchten diese Möglichkeit auf Administratoren beschränken. Sie können mit einem Skript auch den Eigner der Sperre per E-Mail darüber informieren, wenn seine Sperre gestohlen wurde.
Lesen Sie „Serverseitige Aktionsskripte“ für weitere Informationen.