Versionskontrolleure im Vergleich

18.02.2005
Von   
Bernhard Steppan arbeitet als IT-Chefarchitekt bei DB Systel GmbH (Deutsche Bahn) in Frankfurt am Main. Er hat 100+ Artikel und zahlreiche Bücher über C++ und Java verfasst. Er betreibt mehrere Blogs, unter anderem http://steppan.net, http://artouro.org und http://tourbine.com

Der Anwender arbeitet bei CVS nicht online auf dem Repository (Master), sondern wie allgemein üblich auf einer lokalen Arbeitskopie, die er vom Server auschecken muss. Die Bedienung von CVS ist extrem einfach. Wer dennoch Fragen hat, wird mit Dokumentation und Büchern regelrecht überschüttet. Allerdings darf das große Angebot an Literatur nicht darüber hinwegtäuschen, dass bei der praktischen Arbeit oftmals die Grenzen des Werkzeugs erreicht werden.

CVS verwaltet Verzeichnisse als Module. Es speichert jedoch nur die Historie von einzelnen Dateien und nicht den Zusammenhang einer Konfiguration. Gerade bei der Java-Softwareentwicklung löst dies einige Schwierigkeiten aus, da diese Programmiersprache Packages und Klassen auf Verzeichnisse und Dateien abbildet. Werden diese Bäume restrukturiert (Refactoring), geht damit zumeist ein Umbenennen, Verschieben oder Löschen von Teilbäumen und Dateien einher. Dies lässt sich mit CVS nur umständlich umsetzen, da das System für solche Aufgaben überhaupt nicht konzipiert wurde.

Inkonsistenter Projektstand

Zudem ist die Fehlerbehandlung bei Transaktionen nicht optimal gelöst, da CVS keine atomaren Operationen unterstützt. Was das bedeutet, wird deutlich, wenn man eine Reihe von Dateien einchecken will, die logisch zusammenhängen. Weisen eine oder mehrere Dateien Konflikte mit anderen Dateien des Repositories auf, gibt es keinen Abbruch der gesamten Aktion. CVS verweigert also nicht die Annahme der gesamten logischen Einheit, sondern checkt alle Dateien ein, die keinen Konflikt auslösen. Dieses Fehlverhalten verursacht einen inkonsistenten Projektstand, der vom Entwickler mühsam wieder zurückgesetzt werden muss.

Problem Binärdateien