CVS
  
 StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern
Veränderung (letzte Korrektur) (Autor, Normalansicht)

Verändert: 4c4
* Wiki, http://ximbiot.com/cvs/wiki/index.php
* <n>Wiki</n>, http://ximbiot.com/cvs/wiki/index.php
CVS. Concurrent Versioning System. OpenSource Tool zur VersionsKontrolle, wird bei der Mehrzahl der Projekte bei der Verwaltung der Projektdateien und der daran durchgeführten Änderungen (Revisionen) eingesetzt.

Das CVS-System besteht aus einer serverseitigen Software, die das Archiv verwaltet und der clientseitigen Software, die dem Entwickler die Kommunikation mit dem Archiv ermöglicht. CVS kann natürlich auch local auf einem einzelnen Rechner verwendet werden (z. B. für Webseiten-Entwicklung oder System-Administration).

Das original Server-cvs steht derzeit nur für Unix-Systeme zur Verfügung, dazupassende Clients gibt es u. a. auch für Windows. Einen Windows-Port der Server-Software gibt es unter http://www.cvsnt.org/.

Details:

Nachteile: Typische Anwendungen:
Resourcen

Download

Windows Clients

Multiplatform Clients

Ergänzungen / Tools

Windows SCC mit CVS

Microsoft hat für Windows eine Standardschnittstelle SCC definiert, so dass für Windows entwickelte Werkzeuge mit verschiedenen Versionskontrollsystemen zusammenarbeiten. Pro Betriebssystem wird ein dezidiertes Versionskontrollsystem als Standard in der Registry eingetragen und kann dann von Tools wie Rational Rose aus angesprochen werden.

Für CVS gibt es verschiedene Adapter, die jedoch nicht alle ausgereift sind:

(Anmerkung: Ich habe beide mit Rational Rose ausprobiert und bin mit Igloo erheblich besser gefahren als mit dem Zeus-Adapter. Ist aber schon 'ne Weile her.)

Diskussion

Schwächen von CVS bei der Konflikt-Lösung:

Wenn zwei Programmierer unabhängig zwei Änderungen an der gleichen Quelle vornehmen, so übernimmt CVS beide Änderungen, wenn sie nicht an derselben Stelle der Quelle erfolgen ("automatisches Vereinigen"). Nur wenn sie an derselben Stelle erfolgen, meldet CVS einen Konflikt.

Zwei Änderungen können jedoch auch dann miteinander unverträglich sein, wenn sie nicht an derselben Stelle erfolgen. Z.B. könnten die beiden Programmierer bemerken, dass die lokale Variable v nicht initialisiert worden ist. Daher fügt der eine "v = 0;" vor einer gewissen Anweisung S ein, der andere fügt "v = 1;" nach S ein. Jede dieser Änderungen wäre für sich vielleicht in Ordnung; CVS würde aber beide übernehmen, da die trennende Anweisung S dazwischen steht (vorausgesetzt, jede Anweisung steht auf einer eigenen Zeile). Auch zur Übersetzungszeit würde die doppelte, widersprüchliche Initialisierung i.a. nicht bemängelt.

Demgegenüber bemerkt die Programmierumgebung LavaPE? von SpracheLava sowohl fehlende, als auch doppelte Initialisierungen sofort zur Programmierzeit (es gibt keine Übersetzungszeit, Lava wird interpretiert). Ein in LavaPE? integriertes Lava-spezifisches Misch- und Versionsverwaltungssystem könnte daher solche Konflikte, im Gegensatz zu dem sprachunabhängigen CVS, erkennen und melden. Dies relativiert das öfter zu hörende Argument, eine Programmiersprache sollte eine TextuelleRepräsentation haben, um eine wirksame Versionsverwaltung nach Art von CVS zu ermöglichen. Wenn SubVersion tatsächlich auch für binäre Daten zuverlässig funktionieren sollte, so wäre dies eine zweite solche Relativierung.

Übrigens kann diese Schwäche einer sprachunabhängigen Versionsverwaltung bei bestimmten Sprachen zur praktischen Unbrauchbarkeit der Versionsverwaltung führen. Z.B. benutzen die (textuellen) *.dsp-Projektbeschreibungs-Dateiens von MS Developer Studio 6 (eine Art Makefiles) eine Sprache, die Make-Optionen mit "add"- und "sub"-Befehlen gegenüber der Voreinstellung hinzufügt oder entfernt. Ein simples Merge nach CVS-Art hat dann sehr häufig fatale Folgen. Um dies zu vermeiden, sind wir daher dazu übergegangen, diese *.dsp-Dateien gegenüber unserem CVS als binär zu deklarieren, obwohl sie eigentlich textuell sind. (Binärdateien werden nur als Ganzes in CVS ersetzt.) --kg

Bezüglich der textuellen Repräsentation ist dies ein Pseudoargument. Es ist klar, dass unspezifische Tools nicht alle Konflikte automatisch lösen und alle Änderungen automatisch zusammenführen können. Die Lösung der Konflikte ist halt Aufgabe der Entwickler, die von Tools unterstützt werden können - und wie man am Beispiel CVS sieht, können solche Systeme häufig, aber nicht immer, bei textuell repräsentierbaren Dateien die Änderungen darstellen und zusammenführen. Bei Binärdateien ist ein universell einsetzbares System nicht machbar, weil die Formate der Binärdateien dem System nicht bekannt sind.

"Die Lösung der Konflikte ist halt Aufgabe der Entwickler...": einverstanden. Ich wollte auch nur auf zwei Dinge hinweisen: 1. Die Erkennung von Konflikten könnte durch sprach-angepasste Versionsverwaltungssysteme, die auf nicht-textuellen Repräsentationen arbeiten, erheblich verbessert werden. 2. CVS-artige sprach-unabhängige Systeme können u.U. zu fatalen Mischergebnissen oder zu unbemerkt bleibenden Mischkonflikten führen.

Da hast Du zweifellos recht. Nur ist das bestimmt nicht so einfach, denn die Konflikte können auch in verschiedenen Dateien liegen. Ich nehme an, eine Abhilfe könnten Systeme wie CruiseControl sein, die nach jedem Einchecken das Projekt bauen, die Testsuite starten und die Fehlermeldungen an die Entwickler rummailen.

Wir haben uns aber von dem Thema "textuelle Repräsenation" jetzt etwas entfernt - dazu möchte ich noch anmerken: Das binäre Format von Dateien macht es ohne spezielle Tools nicht möglich, die Änderungen der Versionen dem Benutzer zu präsentieren. Die textuelle Repräsenation macht dies einfacher. Aber auch sie ist nicht ein Allheilmittel: Vor allem Dateien, deren exakte Formatierung nicht relevant ist, werden oft von Editoren "umformatiert", was zur Folge hat, dass man zwar Änderunegn erkennen kann, man kann aber schlecht die relevanten von den irrelevanten Formatierungsänderunegn unterscheiden. Beispiele: RTF editieren mit Word, oder XML editieren mit XMLSpy.

Ich möchte auch CVS nicht madig machen. Im Gegenteil: Wir sind von Microsoft's Visual SourceSafe auf CVSNT/WinCVS? umgestiegen, nachdem wir mehrmals mit VSS schlimme Datenverluste und Fehlfunktionen erlebt hatten; seitdem hatten wir mit CVS nie wieder Probleme. --kg

Das habe ich auch nicht so verstanden :-) Ein Tipp: Ich benutze als TortoiseCvs - sehr empfehlenswert. -- GregorRayman

Habe ich auch schon mal ausprobiert. Aber da ich den Windows Explorer nicht benutze, in den Tortoise integriert ist, sondern den TotalCommander liebgewonnen habe, und da ich unter Linux den eineiigen Zwillingsbruder gCvs von WinCVS? (beide http://www.wincvs.org) benutze, habe ich dann wieder davon Abstand genommen. Trotzdem danke. --kg

Dies ist auch insofern ein Pseudoargument, weil sich durchaus Konflikte ergeben können, die über die Grenzen einer Datei hinausgehen. Wenn zwei Programmierer unabhängig in unterschiedlichen Dateien die gleiche Funktion implementieren, wird der C Linker meckern, obwohl das Versionsverwaltungssystem keinen Konflikt bemerkt hat. Dateien als nicht transparente Blobs zu behandeln hilft hier nicht.

Was SubVersion angeht: Die Behandlung der Binärdateien ist gegenüber CVS nur technisch verbessert - d.h. Subversion speichert und überträgt bei Binärdateien nur die Änderungen, nicht ganze Dateien. Konflikte beim Ändern einer Binärdatei kann auch SubVersion nicht lösen. -- GregorRayman

KategorieAbkürzung KategorieSoftwareTool KategorieVersionskontrolle
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern
Text dieser Seite ändern (zuletzt geändert: 19. Januar 2006 16:31 (diff))
Suchbegriff: gesucht wird
im Titel
im Text