www.knebler.de » CVS

Concurrent Version Management (CVS)

knebler — Thu, 10 Apr 2008 06:55:21 +0000

CVS wird zur Softwareversionsverwaltung eingesetzt. Mehrere Entwickler können gleichzeitig an einem Projekt arbeiten. Die Sourcen werden zentral im sogenannten Repository verwaltet, jeder Entwickler arbeitet mit einer lokalen Kopie.

CVS-Ablaufplan

CVS-Vorteile

Alle Entwickler arbeiten mit den Richtigen Quellen.
Es entsteht eine Ãœbersicht der Projekte und dessen Status.
Der Programmiercode wird Dokumentiert.
Die Qualitätskontrolle wird vereinfacht.
Anwendungen werden besser programmiert.

CVS-Nachteile

Es müssen Regeln für die Programmierung aufgestellt werden.
Es müssen Regeln für den Umgang mit CVS erarbeitet werden.
Es müssen Schulungen für Anwender und Administratoren durchgeführt werden.
Neue Software muß eingeführt werden.

CVS Befehlsübersicht

Checkout: Projektname (Modulname)
Import: Projektname (Modulname)
Add: Eine neue Datei oder ein neues Verzeichnis zum Repository hinzufügen.
Get: Eine lokale Kopie des Repositories anlegen.
Commit: Ã„nderungen ins Repository eintragen.
Diff: Unterschiede zwischen lokaler Kopie und Repository anzeigen.
Log: CVS Log Information anzeigen.
Rdiff: Eine Sammlung von Diffs zur Anzeige von Versionsunterschieden erzeugen.
Status: Status der lokalen Dateien im Vergleich zum Repository anzeigen.
Update: Die lokale Kopie des Repositories aktualisieren.

CVS-Clients

WIN-CVS CVS client für Windows, Macintosh and UnixÂ´
TortoiseCVS rechte Mause
gCVS
CVS client für Windows, Macintosh and Unix
jCVS
CVS Java client.
CVSweb

CVS Befehlsübersicht

knebler — Thu, 28 Jun 2007 07:15:30 +0000

Checkout: Projektname (Modulname)

Import: Projektname (Modulname)

Add: Eine neue Datei oder ein neues Verzeichnis zum Repository hinzufügen.
Get: Eine lokale Kopie des Repositories anlegen.

Commit: ï¿½nderungen ins Repository eintragen.

Diff: Unterschiede zwischen lokaler Kopie und Repository anzeigen.

Log: CVS Log Information anzeigen.

Rdiff: Eine Sammlung von Diffs zur Anzeige von Versionsunterschieden erzeugen.

Status: Status der lokalen Dateien im Vergleich zum Repository anzeigen.

Update: Die lokale Kopie des Repositories aktualisieren.

CVS Befehlsübersicht

knebler — Tue, 19 Jun 2007 11:00:00 +0000

Checkout: Projektname (Modulname)

Import: Projektname (Modulname)

Add: Eine neue Datei oder ein neues Verzeichnis zum Repository hinzufï¿½gen.
Get: Eine lokale Kopie des Repositories anlegen.

Commit: ï¿½nderungen ins Repository eintragen.

Diff: Unterschiede zwischen lokaler Kopie und Repository anzeigen.

Log: CVS Log Information anzeigen.

Rdiff: Eine Sammlung von Diffs zur Anzeige von Versionsunterschieden erzeugen.

Status: Status der lokalen Dateien im Vergleich zum Repository anzeigen.

Update: Die lokale Kopie des Repositories aktualisieren.

CVS Terminologie

knebler — Mon, 19 Feb 2007 11:00:00 +0000

Archiv Die Hauptkopie, in der CVS die vollständige Revisionshistorie eines Projektes speichert. Jedes Projekt hat genau ein Archiv.
Revision
Eine Veränderung an einer Datei oder Menge von Dateien, die durch einen Commit abgeschlossen wurde. Eine Revision ist eine Momentaufnahme eines sich ständig verändernden Projektes.
Arbeitskopie
Die Kopie, mit der gearbeitet wird und die tatsächlich verändert wird. Es kann mehrere Arbeitskopien eines bestimmten Projektes geben; im Allgemeinen hat jeder Entwickler seine eigene Kopie.
Checkout
Eine Arbeitskopie von dem Archiv anfordern. Die angeforderte Kopie stellt den Zustand des Projektes zu dem Zeitpunkt dar, zu dem die Kopie angefordert wurde; wenn Sie oder andere Entwickler Veränderungen vornehmen, müssen commit und update durchgeführt werden, um die eigenen Veränderungen zu Â»veröffentlichenÂ« und die der anderen Mitentwickler sehen zu können.
Commit
Senden der eigenen Veränderungen zum zentralen Archiv. Auch Check-in genannt.
Log-Nachricht
Ein Kommentar der bei einem Commit einer Revision angehängt wird und die vorgenommenen Veränderungen beschreibt. Andere Entwickler können durch die Log-Nachrichten blättern und erhalten so die Antwort auf die Frage, was in dem Projekt passiert ist.
Aktualisierung (update)
Veränderungen von anderen Entwicklern vom Archiv in die eigene Arbeitskopie aufnehmen und aufzeigen, ob die eigene Arbeitskopie noch nicht durch commit abgeschickte Veränderungen enthält.
Konflikt
Situation, in der zwei Entwickler Veränderungen im gleichen Teil der gleichen Datei per commit abzuschicken versuchen. CVS bemerkt solche Konflikte und benachrichtigt die Entwickler, aber die Entwickler müssen diese selbst auflösen.

Die Arbeit mit CVS

knebler — Mon, 19 Feb 2007 11:00:00 +0000

Zu Beginn der Arbeit holen Sie sich die aktuellen Fassungen der Dateien vom Server (Menü: Cvs Folders -> Update folder) Sie bearbeiten die Dateien wie üblich. Wenn Sie fertig sind, aktualisieren Sie die Dateien auf dem Server, entweder einfach das ganze Verzeichnis (Menü: Cvs Folders -> Commit folder) oder Sie markieren die veränderten Dateien und aktualisieren nur diese (Menü: Selections -> Update selection). WinCVS zeigt ihnen dabei als Hilfe die Dateien, die verändert wurden. Haben Sie neue Dateien zu Ihrem Projekt hinzugefügt, fügen Sie diese mit Selections->Add selection bzw. Selections->Add selection binary zum Projekt hinzu. Ab dann stehen auch diese Datein unter CVS-Kontrolle. Veränderungen zurücknehmen Eine Methode des Update ist es, die Option -j (für Â»joinÂ«) zu dem update-Kommando zu verwenden. Diese Option verwendet Revisionsnummern als Argumente und kann bis zu zwei Mal angegeben werden. CVS bestimmt dann die Unterschiede zwischen den beiden angegebenen Revisionen und wendet diese als Patch auf die fragliche Datei an. Die Reihenfolge, in der die Revisionen angegeben werden, ist daher von entscheidender Bedeutung cvs update -j 1.4 -j 1.3 XXX

CVS Szenario

knebler — Fri, 19 Jan 2007 11:00:00 +0000

wei Entwickler, A und B, führen gleichzeitig einen Checkout des gleichen Projektes aus. Das Projekt befindet sich noch am Ausgangspunkt – es wurden noch von niemandem Veränderungen per Commit an das Archiv geschickt, sodass sich noch alle Dateien in ihrem ursprünglichen Zustand befinden. Entwickler A beginnt sofort mit seiner Arbeit und führt schon bald den ersten Commit seiner Ã„nderungen aus. In der Zwischenzeit sieht Entwickler B fern. Entwickler A arbeitet, als ob es kein Morgen gäbe, und führt einen zweiten Commit für einen weiteren Satz von Veränderungen aus. Das Archiv enthält nun die Originaldateien, gefolgt von As zweitem Satz von Veränderungen, gefolgt von diesem Satz an Veränderungen. In der Zwischenzeit spielt Entwickler B Videospiele oder so…. Plötzlich schließt sich Entwickler C dem Projekt an und macht einen Checkout einer Arbeitskopie aus dem Archiv. Die Kopie von Entwickler C enthält As erste zwei Sätze von Veränderungen, weil diese schon im Archiv enthalten waren, als C für seine Arbeitskopie einen Checkout gemacht hat. Entwickler A arbeitet weiter wie von Geistern besessen, vollendet seinen dritten Satz an Veränderungen und führt abermals einen Commit aus. Zu guter Letzt, nichts ahnend von der jüngsten rasanten Aktivität, entscheidet Entwickler B, dass es Zeit wird, an die Arbeit zu gehen. Er kümmert sich nicht darum, eine Aktualisierung seiner Arbeitskopie durchzuführen; er fängt an, Dateien zu bearbeiten, von denen einige jene Dateien sein könnten, an denen A gearbeitet hat. Kurz darauf führt Entwickler B seinen ersten Commit dieser Veränderungen aus. An diesem Punkt können nun zwei Dinge passieren. Wenn keine der von Entwickler B bearbeiteten Dateien von A bearbeitet wurde, dann ist der Commit erfolgreich. Wenn CVS jedoch merkt, dass einige der Dateien von B verglichen mit den aktuellen Dateien des Archivs veraltet sind und diese auch von B in seiner Arbeitskopie verändert wurden, informiert CVS B darüber, dass er eine Aktualisierung durchführen muss, bevor ein Commit durchgeführt werden kann. Wenn Entwickler B die Aktualisierung durchführt, fügt CVS alle Veränderungen von A in Bs lokale Kopien der Dateien ein. Einige von As Veränderungen können mit Bs noch nicht abgeschickten Veränderungen in Konflikt geraten, manche nicht. Die Teile, welche nicht in Konflikt stehen, werden einfach ohne weitere Komplikationen in Bs Kopie eingefügt; die in Konflikt stehenden müssen zuerst von B bereinigt werden, bevor der Commit durchgeführt werden kann. Wenn Entwickler C nun eine Aktualisierung durchführt, bekommt er mehrere Sätze an Veränderungen aus dem Archiv: den dritten Commit von A, den ersten von B und vielleicht den zweiten von B (wenn B die Konflikte aufgelöst hatte). Damit CVS Veränderungen in der richtigen Reihenfolge an die Entwickler verteilen kann, deren Arbeitskopien unter Umständen unterschiedlich stark veraltet sind, muss das Archiv alle Commits seit Projektbeginn aufzeichnen. In der Praxis speichert das CVS-Archiv diese als aufeinander folgende Diffs. Daher kann CVS auch noch für sehr alte Arbeitskopien den Unterschied zwischen den Dateien der Arbeitskopien und dem aktuellen Stand des Archivs bestimmen und dadurch die Arbeitskopie effizient wieder auf den aktuellen Stand bringen. Für Entwickler ist es dadurch einfach, die Historie des Projektes einzusehen und zu jedem Zeitpunkt sogar sehr alte Arbeitskopien wieder zum Leben zu erwecken.

Versionskontrolle mit CVS

knebler — Fri, 19 Jan 2007 11:00:00 +0000

CVS ist das “Concurrent Version Management”, ein mächtiges Werkzeugs für Versionsmanagement und kooperativer Programmentwicklung. Es erlaubt das gemeinsame Editieren von beliebigen ASCII-Dateien (eingeschränkt auch BIN-Dateien)
Mehrere Entwickler können gleichzeitig von beliebigen Standorten an einem Projekt arbeiten. Die Sourcen werden zentral im sogenannten Repository verwaltet, jeder Entwickler arbeitet mit einer lokalen Kopie.
Es steht dem Nutzer frei, wann und wie er seinen Stand dem Serverstand angleicht, und wann er seine veränderten Dateien dem Repository zufügt.
Innerhalb des Repositorys können mehrere Dateien zu Modulen zusammengefasst werden. Will man eines dieser Module bearbeiten, so muß man zunächst einen “checkout” machen, der eine lokale Kopie anlegt.
Es gibt die Möglichkeit, mehrere Zweige (Branches) zu benutzen. So können z.B. zwei verschiedene Ansätze verfolgt werden. Sollen diese wieder zusammengefügt werden, ist dies durch einen “Merge” möglich. Durch einen zusätzlichen Parameter beim “checkout” kann man einen bestimmten Branch erhalten.

Obwohl die eigentliche Heimat von CVS die Unix-Welt ist, gibt es inzwischen auch eine Windows-Version unter GPL. Durch die Ersetzung des Kommandozeileninterfaces des eigentlichen CVS durch eine Menüoberfläche läßt es sich hier einfacher nutzen. Leider ist die Konfiguration etwas aufwendig .
Zunächt muß man dem WinCVS mitteilen, auf welches Repository man zugreift. Ein Repository kann im Filesystem liegen, aber auch über verschiedenen Arten remote angesprochen werden. Bei CVS wird es durch die Variable CVSROOT definiert.
Im Normalfall handelt es sich um ein entferntes Repository, dass mit der Methode “pserver” angesprochen wird. Hier meldet man sich am CVS-Server mit dem Nutzernamen “XXX” Projekt und Passwd an. Die Methode “pserver” ist der Standard im Internet, er impliziert eine Passwortauthentifikation.
Falls man hinter einem Firewall arbeitet, kann der HTTP Proxy für den Zugriff auf dem CVS-Server eingesetzt werden. (bei direkter Verbindung kann auch das SSH Protokoll verwendet werden)

Der erste initialen “checkout”, der eine Kopie des aktuellen PROJEKTS anlegt.
[Create] [checkout module]-”XXX” im Menü, das entspricht dem Befehl “CVS checkout XXX”
Auf der lokalen Kopie kann nun wie gewohnt mit einem Editor oder einer Entwicklungsumgebung gearbeitet werden.

CVS Befehlsübersicht
Befehl und dessen Wirkung

Checkout: Projektname (Modulname)

Import: Projektname (Modulname)

Add: Eine neue Datei oder ein neues Verzeichnis zum Repository hinzufügen.

Get: Eine lokale Kopie des Repositories anlegen.

Commit: Ã„nderungen ins Repository eintragen.

Diff: Unterschiede zwischen lokaler Kopie und Repository anzeigen.

Log: CVS Log Information anzeigen.

Rdiff: Eine Sammlung von Diffs zur Anzeige von Versionsunterschieden erzeugen.

Status: Status der lokalen Dateien im Vergleich zum Repository anzeigen.

Update: Die lokale Kopie des Repositories aktualisieren.

Mit dem Menu-Befehl [Trace][Release Selection] kann man einen Release eines Moduls erstellen. Ein Release ist eine Version ohne jegliche CVS-Informationen, der zur Produktion eingesetzt werden kann.

Neue Datei anlegen und zufügen:
[Modify][add Selection] unter WinCVS, “CVS add dateiname” in der Kommandozeilenvariante.

Vorhandenes lokales Modul aktualisieren :
Rechte Maustaste-”update selection” in der Windows-Variante, sonst “CVS update dateiname”.

Was ist seit meinem letzten checkout/update/commit passiert?
Rechte Maustaste-”diff selection”, sonst “CVS diff dateiname”.

Wie ein Konflikt entsteht: Man versucht eine veränderte Datei zu commiten, die in der Zwischenzeit bereits von jemand anders bearbeitet wurde – und das in den gleichen Zeilen. Diesen Konflikt kann CVS nicht mehr selbsttätig lösen, als gibt es eine Konflikt-Meldung aus. In der Windowsvariante erhält diese Datei das Tag “C” für “Conflict”, und sie enthält – mit einigen automatisch generierten Kommentaren – beide Versionen. Das Tag und den Status “Conflict” verliert diese Datei erst, wenn sie bearbeitet und neu commitet, also zum Repository zugefügt wurde.

Um mit CVS effektiv zu arbeiten sollten einige Regeln und Guidelines aufgestellt und beachtet werden.
TIP: Java bietet eine ganze Reihe sinnvoller Coding Guides.Was kann CVS?

Dokumentieren

Protokollieren

Kommunizieren

CVS-Vorteile!

Alle Entwickler arbeiten mit den Richtigen Quellen.

Es entsteht eine Ãœbersicht der Projekte und dessen Status.

Der Programmiercode wird Dokumentiert.

Die Qualitätskontrolle wird vereinfacht.

Anwendungen werden besser programmiert.

CVS-Nachteile!

Es müssen Regeln für die Programmierung

aufgestellt werden.

Es müssen Regeln für den Umgang mit CVS erarbeitet werden.

Es müssen Schulungen für Anwender und Administratoren durchgeführt werden.

Neue Software muß eingeführt werden.