8 Verwendung der Schlüsselwortexpansion

Sie erinnern sich vielleicht daran, dass Schlüsselwortexpansion kurz in Kapitel 2 erwähnt wurde. RCS-Schlüsselwörter sind spezielle Wörter, die in Dollarzeichen eingeschlossen sind und die CVS aus Textdateien heraussucht und zu Revisions-Kontrollinformationen expandiert. Wenn beispielsweise eine Datei

$Author$

enthält, dann wird CVS das beim Update dieser Datei auf eine bestimmte Revision durch den Benutzernamen derjenigen Person expandieren, die für den Commit der Revision verantwortlich ist:

$Author: jrandom $

CVS kümmert sich um diese Schlüsselwörter auch in ihrer expandierten Form, sodass sie, selbst wenn sie schon einmal expandiert wurden, auch weiterhin aktualisiert werden.

Obwohl Schlüsselwörter keine Informationen liefern, die nicht auch auf anderen Wegen erreichbar sind, bieten sie doch eine bequeme Möglichkeit, die Fakten über die Revisionskontrolle in die Textdatei einzubetten, sodass man keine obskuren CVS-Operationen durchführen muss.

Hier ein paar weitere gebräuchliche Schlüsselwörter:

$Date$ ==> Datum des letzten Commit, wird zu ==> $Date: 1999/07/26 06:39:46 $

$Id$ ==> Dateiname, Revision, Datum und Autor, wird zu ==> $Id: hello.c,v 1.11 1999/07/26 06:39:46 jrandom Exp $

$Revision$ ==> genau was Sie denken, wird zu ==> $Revision: 1.11 $

$Source$ ==> Pfad zur korrespondierenden Datei im Archiv, wird zu ==> $Source: /usr/local/newrepos/tossproj/hello.c,v $

$Log$ ==> sammelt Log-Nachrichten für diese Datei an, wird zu ==> $Log: hello.c,v $

Revision 1.2 1999/07/26 06:47:52 jrandom ...and this is the second log message.

Revision 1.1 1999/07/26 06:39:46 jrandom This is the first log message...

Das Schlüsselwort $Log$ ist hierbei das einzige, das zu mehreren Zeilen expandiert wird. Es ersetzt nicht - wie die anderen - die alte Expansion durch eine neue, sondern fügt direkt nach dem Schlüsselwort die neuste Expansion und zusätzlich noch eine Leerzeile ein. So wird die vorige Expansion weiter nach unten geschoben. Außerdem wird noch jeder Text, der zwischen dem Anfang der Zeile und $Log$ steht, den expandierten Zeilen vorangestellt, damit die Log-Nachrichten im Quelltext einkommentiert werden. Wenn Sie beispielsweise das

// $Log$

in die Datei schreiben, wird es beim ersten Commit zu so etwas:

// $Log: hello.c,v $
// Revision 1.14 1999/07/26 07:03:20 jrandom
// this is the first log message...
//

Beim zweiten Commit:

// $Log: hello.c,v $
// Revision 1.15 1999/07/26 07:05:34 jrandom
// ...and this is the second log message...
//
// Revision 1.14 1999/07/26 07:03:20 jrandom
// this is the first log message...

Und so weiter:

// $Log: hello.c,v $
// Revision 1.16 1999/07/26 07:05:34 jrandom
// ...and this is the third!
//
// Revision 1.15 1999/07/26 07:04:40 jrandom
// ...and this is the second log message...
//
// Revision 1.14 1999/07/26 07:03:20 jrandom
// this is the first log message...
//

Wenn Sie nicht die gesamte Entwicklung der Log-Datei in Ihrer Datei haben wollen, können Sie die älteren Abschnitte entfernen, wenn es Ihnen zu lang wird. Die von $Log$ zur Verfügung gestellte Funktionalität ist mit Sicherheit komfortabler, als cvs log zu bemühen, und mag sich bei Projekten lohnen, bei denen die Log-Dateien ständig gelesen werden müssen.

Eine üblichere Technik ist es, $Revision$ in die Datei mit aufzunehmen und es als Versionsnummer des Programms zu verwenden. Das ist möglich, wenn das Projekt im Wesentlichen aus einer Datei besteht oder häufig neue Versionen veröffentlicht werden und sich eine Datei bei jeder neuen Version garantiert ändert. Sie können sogar die RCS-Schlüsselwörter direkt im Quelltext des Programms benutzen.

VERSION = "$Revision: 1.114 $";

CVS wird das Schlüsselwort wie jedes andere expandieren, es hat keine Vorstellung von der Semantik der Programmiersprache und geht nicht davon aus, dass die Anführungszeichen die Zeichenkette in irgendeiner Form schützen sollen.

Eine komplette Liste der Schlüsselwörter (es gibt noch ein paar weitere, ziemlich obskure) gibt es in Kapitel 9.

9 Eine prekäre Lage: Wie überlebt man die Arbeit mit Verzweigungen?

Verzweigungen sind gleichzeitig eine der wichtigsten und am leichtesten mißbrauchten Fähigkeiten von CVS. Es kann sehr hilfreich sein, wenn man gefährliche oder störende Änderungen in einer getrennten Entwicklungslinie isoliert, bis sie sich stabilisiert haben. Wenn sie jedoch nicht richtig gemanagt werden, können Verzweigungen ein Projekt ganz schnell in Verwirrung und Chaos stürzen, nämlich wenn die Entwickler den Überblick verlieren, welche Änderungen wann wieder zusammengeführt wurden.

Um erfolgreich mit Verzweigungen arbeiten zu können, sollte sich die Entwicklergruppe an folgende Regeln halten:

Halten Sie die gleichzeitig aktiven Verzweigungen möglichst klein. Je mehr Verzweigungen zur gleichen Zeit entwickelt werden, umso wahrscheinlicher ist es, dass sie Konflikte erzeugen, wenn sie zurück in die Hauptversion einfließen sollen. In der Praxis erreicht man das, indem man die Verzweigungen so häufig wie möglich (sobald eine Zweigversion an einem stabilen Punkt angelangt ist) mit der Hauptlinie verschmilzt und die Entwicklungsarbeit an der Hauptversion fortsetzt. Indem man die parallel laufenden Entwicklungen klein hält, kann jeder besser nachvollziehen, was in welcher Verzweigung vorgeht, und die Wahrscheinlichkeit, dass Konflikte auftreten, wird kleiner.

Minimieren Sie die Komplexität - also die Tiefe - in Ihrem Verzweigungsplan. Es mag Umstände geben, wo es angemessen ist, Verzweigungen einer Verzweigung zu haben, aber die sind spärlich gesät. (Man kann ein ganzes Leben lang programmieren, ohne jemals auf eine zu stoßen.) Nur weil CVS es ermöglicht, beliebig viele Ebenen von verschachtelten Verzweigungen zu haben und beliebige Verzweigungen zu vereinen, heißt das noch lange nicht, dass Sie das auch wollen. In den meisten Situationen ist es am besten, dass alle Verzweigungen ihre Wurzel in der Hauptversion haben und auch dahin zurückkehren.

Benutzen Sie einheitlich benannte Marken, um all ihre Verzweigungs- und Zusammenführungsereignisse zu kennzeichnen. Im Idealfall sollte die Bedeutung jeder Marke und ihr Verhältnis zu den übrigen Verzweigungen allein durch den Namen offensichtlich sein. (Dieser Punkt wird noch anhand der Beispiele klarer werden.)

Mit diesen Regeln im Kopf wenden wir uns nun einem typischen Szenario mit verzweigter Entwicklungsarbeit zu. Wir werden jrandom an der Hauptversion und qsmith an einer abgezweigten Version haben. Bedenken Sie aber, dass genauso gut mehrere Entwickler an beiden tätig sein könnten. Die normale Entwicklungsarbeit an jedweder Linie kann beliebig viele Personen umfassen, die Benennung und Zusammenführung überlässt man aber am besten genau einer Person auf jeder Seite, wie Sie gleich sehen werden.