2.2.6 CVS Locks im Repository

Ein Einführung zu CVS locks, die sich auf das Benutzerbezogene Verhalten beziehen, können Sie unter 10.5 Several developers simultaneously attempting to run CVS erhalten. Der folgenden Abschnitt ist an die jenigen gerichtet, die Werkzeuge erstellen möchten, die auf das Repository in Zusammenhang mit anderen Werkzeugen auf das gleiche CVS Repository zugreifen. Wenn Sie sich durch die hier beschriebenen Konzepte verwirrt fühlen, wie bspw. read lock, write lock oder deadlock, dann sollten Sie Literatur zum Thema Betriebssysteme oder Datenbanken konsultieren.

Jede Datei im Repository deren Name mit `#cvs.rfl.' beginnt ist eine lese Sperre, `#cvs.wfl' eine schreib Sperre. Ältere Versionen von CVS (vor CVS 1.5) haben zusätzlich noch Dateien beginnend mit `#cvs.tfl' erzeugt, die wir aber hier nicht behandeln. Das Verzeichnis `#cvs.lock' stellt einen Master Sperre dar. Das heißt, daß diese vor allen anderen Sperren erzeugt werden muß.

Um eine Lese--Sperre zu erstellen, muß zuerst das Verzeichnis `#cvs.lock' erzeugt werden, wobei das eine atomare Operation sein muß (sollte für die meisten Betriebssystem gelten). Wenn das fehlschlägt, weil das Verzeichnis schon vorhanden ist, so muß einige Zeit gewartet werden und ein neuer Versuch gestartet werden. Wenn eine Sperre der Form `#cvs.lock' erzeugt wurde, erzeugen Sie eine Datei deren Namen mit `#cvs.rfl.' beginnt und noch einige Informationen Ihrer Wahl folgen (bspw. Hostname und Prozeßidentifikationsnummer). Danach entfernen Sie die Verzeichnis Master Sperre `#cvs.lock' wieder und fahren mit dem lesen des Repositories fort. Wenn Sie fertig sind, entfernen Sie die `#cvs.rfl' Datei und geben die Lese Sperre frei.

Um eine Schreib--Sperre zu bekommen, muß zuerst ein `#cvs.lock' Verzeichnis erzeugt werden, genau wie bei der Lese--Sperre. Dann muß geprüft werden, ob dort keine Dateinamen mit dem prefix `#cvs.rfl.' sind. Sollten welche da sein, so muß das Verzeichnis `#cvs.lock' wieder entfernt werden und einige Zeit gewartet werden und dann ganze muß nochmal von vorne losgehen. Wenn da keiner ist, der lesend zugreift, dann erezeugen Sie eine Datei `#cvs.wfl', wo bei zusätzliche Informationen an den Dateinamen angehängt werden können. Beispielsweise der Hostname und die Prozessidentifikationsnummer. Entfernen Sie das Verzeichnis `#cvs.lock' (Schreib--Sperre). Fahren Sie mit dem schreibenden Zugriff auf das Repository fort. Wenn Sie damit fertig sind, muß zuerst die Datei `#cvs.wfl' und dann das Verzeichnis `#cvs.lock' entfernt werden. Beachten Sie bitte, daß sowohl die Datei `#cvs.rfl' als auch die Datei `#cvs.wfl' nur informativen Character besitzen. Es hat keine eigendliche Auswirkung auf die Sperrung selbst.

Es ist weiterhin wichtig zu beachten, daß jede Art von Sperre (schreib-- oder lesensperre) lediglich ein einzelnes Verzeichnis im Repository sperrt, wobei das Verzeichnis `Attic' und `CVS' enthalten sind, aber nicht eventuell vorhandene Unterverzeichnise, die weitere Verzeichnise darstellen, die unter Versionskontrolle stehen. Um nun einen ganzen Verzeichnisbaum zu sperren, müssen Sie jedes einzelne Verzeichnis sperren. Sollte dabei die Sperrung eines einzigen Verzeichnises fehlschlagen, so muß der gesamte Baum wieder freigegeben werden bevor ein erneuter Versuch gestartet werden kann. Das ist zur Vermeidung von s.g. Dead--locks nötig.

Beachten Sie daß CVS eine Schreibsperre als Zugriffskontrolle auf eine einzelne Datei `foo,v' erwartet. RCS verwendet `,foo,' als eine Sperre aber in CVS wurde das nicht implementiert, somit wird angeraten, eine CVS Schreibsperre zu verwenden. Schauen Sie sich die Kommentare in rcs_internal_lockfile im CVS Quelltext an, um als weitere Diskussion zu dienen.

[ < ]

[ > ]

[ << ]

[ Up ]

[ >> ]

[Top]

[Contents]

[Index]

[ ? ]