Zurück: Weiterlaufen Inhalt: CVS benutzen Weiter: Stolperfallen

Wettrennen

CVS: eine wundervolle (Zeit-)Maschine, aber keine Wunder-Maschine

Das Haupteinsatzgebiet von CVS ist die Verwaltung von Programmierprojekten, an denen mehrere Entwickler gemeinsam arbeiten. Auf dem Status von CVS als Quasi-Standard in diesem Bereich basiert ein weit verbreiteter Irrglaube. Dieser besagt, daß man nur CVS aufsetzen muß und sich danach nie mehr Sorgen darum machen muß, wer gerade was bearbeitet, weil es durch den Einsatz von CVS nicht mehr zu Konflikten durch gleichzeitige Bearbeitung einer Datei von mehreren Entwicklern kommen könne. Diese Vorstellung ist bestenfalls eine Halbwahrheit.

Der wichtigste Merksatz bei dem Umgang mit CVS ist, daß CVS nur helfen kann, Konflikte zu vermeiden, bzw. zu beseitigen. CVS kann nicht verhindern, daß bei der gemeinsamen Arbeit meherer Entwickler an einem Quellbaum Konflikte entstehen. Dies kann nur durch hinreichende Absprache der Entwickler erreicht werden. (CVS stellt allerdings Hilfsmittel zur Automatisierung dieser Absprache zur Verfügung: watch, use und edit. Dieses Thema wird hier aber nicht mehr behandelt...) CVS ist zwar eine wundersame Zeitmaschine, aber eben keine Wundermaschine! Damit ist gemeint:

CVS weiß nichts über den Sinn der Dateien, die es behandelt. Es kennt nur die Unterschiede zwischen den verschiedenen Versionen der Dateien.

Was macht CVS also, wenn es konkurierende Änderungen an einer Datei feststellt? Es versucht einfach, die unterschiedlichen Änderungen zu einer neuen Version der Datei zusammenzuführen.

Wenn es sich um Änderungen an unterschiedlichen Teilen der Datei handelt, werden diese in einer neuen Version der Datei zusammengeführt. Der Benutzer wird darauf durch den Hinweis merging differences aufmerksam gemacht. Ob die druch diese Zusammenführung entstehende Datei sinnvoll ist oder nicht, ist CVS egal. Es kann darüber ja auch gar nichts wissen: wie sollte CVS bewerten, ob die neue Zusammenführung den Vorstellungen des Benutzers entspricht. Wenn man ein Programm dazu bringen könnte solche Beurteilungen zu treffen, dann könnte man es auch gleich für sich programmieren lassen.
Wenn zwei Dateiversionen, die CVS zusammenzuführen versucht, konkurierende Änderungen an ein und der selben Stelle enthalten, dann kann CVS sie schlicht nicht zu einer Version zusammenführen, da es (analog zum ersten Fall) ja nicht weiß, welche der Änderungen im Sinne des Anwenders Vorrang hat. CVS markiert diese Stellen dann in der Datei und fügt beide Varianten ein. Bevor diese Markierungen von einem Anwender entfernt worden sind, also bevor der entstandene Konflikt von Hand behoben wurde, nimmt CVS die Datei nicht mehr in einem checkin entgegen.

Von der Konkurenz überholt

Wie sieht das nun in der Praxis aus?

Nehmen wir an, wir haben eine Datei lokal verändert und wollen diese Änderungen nun einchecken. Hinter unserem Rücken hat aber ein anderer Benutzer eine Änderung an der selben Datei vorgenommen und diese Änderungen in das Repository eingefügt. Was zunächst passiert ist folgendes:

kai@fREUNd:~/xpenguins$ echo "/* Änderungen... */" >> xpenguins.c
kai@fREUNd:~/xpenguins$ cvs ci xpenguins.c
cvs commit: Up-to-date check failed for `xpenguins.c'
cvs [commit aborted]: correct above errors first!
kai@fREUNd:~/xpenguins$

Welche Fehler meint CVS bloß? Fragen wir CVS doch einfach, was es über den Status der Datei denkt:

kai@fREUNd:~/xpenguins$ cvs stat xpenguins.c
===================================================================
File: xpenguins.c       Status: Needs Merge

   Working revision:    1.3     Sun May 25 16:55:38 2003
   Repository revision: 1.4     /home/kai/cvsroot/xpenguins/xpenguins.c,v
   Sticky Tag:          (none)
   Sticky Date:         (none)
   Sticky Options:      (none)
       
kai@fREUNd:~/xpenguins$

Ach so! Die Version von xpenguins.c in unserem Arbeitsverzeichnis ist nicht auf dem neusten Stand. Sie benötigt eine Zusammenführung mit der Dateiversion im Repository (Status: Needs Merge). CVS besteht also darauf, daß wir uns die neuesten Änderungen aus dem Repository holen, bevor es unsere Änderungen an der Datei akzeptiert. So wird verhindert, daß wir einfach ungewollt die Änderungen des anderen Benutzers rückgängig machen, indem wir unsere ältere Dateiversion, an der wir unsere Änderungen vorgenommen haben, einchecken. (Es wird allerdings nicht verhindert, daß wir einfach die Änderungen des anderen Benutzers nach dem merge von Hand wieder rückgängig machen und dann einchecken, ob das nun Sinn macht, oder nicht -- CVS kann nur verhindern, daß Änderungen anderer aus versehen rückgängig gemacht werden.)

Zurück auf den Stand der Zeit

Um die Datei wieder Up-to-date zu bringen, wird natürlich das CVS-Kommando update benutzt. Zuvor sollte allerdings überprüft werden, ob sich die Änderungen des anderen Benutzers mit den unsrigen vertragen, oder ob es notwendig ist, das wir uns mit diesem einigen, welche Änderungen zu bevorzugen sind. Wir erinnern uns: Mit dem Kommando cvs diff -r1.3 -r1.4 xpenguins.c können wir uns ansehen, welche Änderungen der andere Benutzer vorgenommen hat. Der Aufruf cvs diff -r1.4 xpenguins.c vergleicht die Datei in unserer Arbeitskopie mit der von dem anderen Benutzer neu eingecheckten Version. Schließlich zeigt cvs diff xpenguins noch mal unsere Änderungen an. (Bei dem Aufruf von diff ohne weitere Argumente wird die Datei in unserer Arbeitskopie mit der Version verglichen, die wir ausgecheckt hatten.)

Wenn sich die Änderungen vertragen, können wir unsere Datei auf den Stand der Zeit bringen:

kai@fREUNd:~/xpenguins$ cvs up xpenguins.c
RCS file: /home/kai/cvsroot/xpenguins/xpenguins.c,v
retrieving revision 1.3
retrieving revision 1.4
Merging differences between 1.3 and 1.4 into xpenguins.c
M xpenguins.c
kai@fREUNd:~/xpenguins$

CVS teilt mit, daß es die Differenz zwischen der Dateiversion, die wir ursprünglich ausgecheckt hatten, und der neuen Version ermittelt und mit dem Ergebnis die Datei gepacht hat, die sich in unserem Arbeitsverzeichnis befunden hat. Weiterhin enthält die Datei in unserem Arbeitsverzeichnis unsere Änderungen (M für modified) und wir können diese nun ohne Beschwerde von CVS ins Repository übertragen:

kai@fREUNd:~/xpenguins$ cvs ci -m "Kein Konflikt" xpenguins.c
Checking in xpenguins.c;
/home/kai/cvsroot/xpenguins/xpenguins.c,v  <--  xpenguins.c
new revision: 1.5; previous revision: 1.4
done
You have new mail in /var/mail/kai
kai@fREUNd:~/xpenguins$

Spätestens jetzt sollte man sich mit dem andern Entwickler in Verbindung setzen und sich mit ihm absprechen, bevor es zu unverträglichen Änderungen kommt. CVS bietet einen Mechanismus, der dies vereinfacht: ausgecheckte Dateien werden dann standardmäßig read-only erzeugt. Wenn man eine Datei verändern will, teilt man dies CVS mit dem Kommando edit mit. Die Dateie wird dann schreibbar. Gleichzeitig informiert CVS andere Benutzer über diesen Vorgang, die es per watch dazu aufgefordert haben, die Datei für sie zu "überwachen".

Konfliktbewältigung

Nicht immer verläuft alles so glimpflich, wenn man sich ungenügend mit anderen Entwicklern abgesprochen hat. Angenommen wir haben eine weitere Änderung an xpenguins.c vorgenommen und wollen nun per cvs up überprüfen, ob zwischenzeitlich jemand etwas an anderen Dateien verändert hat, das wir vor unserem checkin noch berücksichtigen sollten. Hinter unserem Rücken hat aber jemand anders eine Änderung an der selben Stelle von xpenguins.c vorgenommen und ins Repository übertragen:

kai@fREUNd:~/xpenguins$ vim xpenguins.c
kai@fREUNd:~/xpenguins$ cvs up
cvs update: Updating .
M README
RCS file: /home/kai/cvsroot/xpenguins/xpenguins.c,v
retrieving revision 1.5
retrieving revision 1.6
Merging differences between 1.5 and 1.6 into xpenguins.c
rcsmerge: warning: conflicts during merge
cvs update: conflicts found in xpenguins.c
C xpenguins.c
cvs update: Updating penguins
kai@fREUNd:~/xpenguins$

CVS hat wieder versucht, unsere lokale Version der Datei mit den Änderungen die inzwischen ins Repository eingetragen wurden zu patchen, ist dabei aber auf einen Konflikt unserer Änderungen mit denen des anderen Entwicklers gestoßen. CVS hat diesen Konflikt in der Datei markiert:

            if (npenguins > MAX_PENGUINS) {
               fprintf(stderr,"Warning: only %d penguins created\n",
                     npenguins=MAX_PENGUINS);
<<<<<<< xpenguins.c
               fprintf(stderr,"Should be some more...\n");
=======
               fprintf(stderr,"And that are not enough!!\n");
>>>>>>> 1.6
            }
            else if (npenguins <= 0) {
               fprintf(stderr,"Warning: no penguins created\n");
                     npenguins=0;
                                                              87,1          16%

Solange dieser Konflikt nicht von Hand behoben wurde, d.h. solange die Markierungen nicht wieder aus der Datei entfernt wurden, nimmt CVS diese Datei bei einem checkin nicht an.

Die Syntax der Markierungen ist möglichst einfach und gleichzeitig eindeutig gewählt. Wenn aber von zwei Entwicklern an ein und der selben Datei intensiv weiterentwickelt wurde, dann nimmt die Anzahl solcher Markierungen schnell eine Größenordnung an, bei der das entfernen der Markierungen und der ungewollten Varianten sehr lange dauert. Konflikte sollten daher möglichst vermieden werden. Sie sind als Mittel der Absprache zwischen mehreren Entwicklern weder gedacht, noch geeignet!

Zurück: Weiterlaufen Inhalt: CVS benutzen Weiter: Stolperfallen