Revision as of 21:42, 7 June 2007

CVS Concurrent Versions System

CVS ist der Klassiker für VersionControl: http://www.cvshome.org

Meine Anforderungen

• Lauffähig auf einem Windows-Entwicklungsrechner mit geringstem Aufwand und möglichst "leichtgewichtig"
• OpenSourceSoftware bzw. GNU GPL bzw. geringe Kosten und hohe Verbreitung

CVS-Server

Möchte im ersten Schritt noch garnicht einsetzen. Es soll ein lokales CVS-Repository auf meinem Windows-Notebook sein, nur für mich allein.
Da Eclipse anscheinend nicht mit :local: arbeitet, sondern :pserver: benötigt, habe ich zu guter Letzt (s.u.) doch noch den CVSNT-Server installiert.

CVS-Client

Die Mainstream-Lösungen sind:

WinCVS:

war mir schon von der Software-Architektur zu aufwendig und nicht in Übereinstimmung mit meiner Architektur (Python, Tcl, GTK).
http://www.wincvs.org

TortoiseCVS:

Eine ganz schlanke Windows-Lösung, die nur auf C++ basiert und sich sehr schön in den Windows Explorer integriert. Wirklich leicht zu benutzen. Basiert auf dem Code von WinCVS, ist aber nicht so komplex.
http://www.tortoisecvs.org/

Eclipse:

Muss man sich wohl in diesem Jahr genauer anschauen. Das scheint die Zukunft zu sein.
http://www.eclipse.org

CVS-Server für Windows: CVSNT

Neben der Möglichkeit einen CVS-Server auf Windows über Cygwin zu realisieren, gibt es eine sehr gute Portierung auf WinNT (Windows 2000,...) CVSNT. Es gibt ganz ausführliche Schritt-für-Schritt-Beschreibungen für die Installation von CVSNT (was auch nötig ist, da es einige Fallstricke gibt).

Meine CVS Projekte (CVS Module)

CVS Lektion 1: Anlegen und Füllen eines CVS-Repositories

Das cvs.exe (mitgeliefert von ZeusEdit, TortoiseCVS oder CVSNT) sollte im PATH sein (also: \Programme\ZeusSCC-CVS oder \Programme\TortoiseCVS oder ...). Es wird einerseits intern von dem jeweiligen SCC-Provider verwendet, andererseits kann es als Kommandozeilen-CVS-Utility unter Windows eingesetzt werden, um z.B. Das CVS-Repository per Hand aufzubauen.

Schritt 1: Initialisieren eines CVS-Repository

	cvs -d:local:d:\home\cvsroot init

Damit man für das weitere Arbeiten mit CVS nicht immer den Parameter -d:local:d:\home\cvsroot angeben muss, setzten wir die dafür vorgesehene Environment-Variable: SET CVSROOT=:local:d:\home\cvsroot.

Schritt 2: Dateien in ein CVS-Repository einstellen ("importieren")

	d:
	cd \home\kracht\www\dietrich.kracht.free.fr\rolodap	 (genannt "Arbeitsverzeichniss")
	cvs import -m"trallala" -d -C rolodap  LONZO V1_00

Damit wird das aktuelle Verzeichnis mit allen Dateien und Unterverzeichnissen unter dem CVS-Modulnamen "rolodap" in das CVS-Repository gestellt. Umgangssprachlich nennt man "CVS-Module" auch gerne "CVS-Projekte". Das "-d" sorgt dafür, dass das Archivierungsdatum aus dem Filedatum genommen wird, und das "-C" sorgt dafür, dass in das Arbeitsverzeichnis interne Verwaltungsinformationen für CVS gleich mitaufgenommen werden (versteckter Ordner CVS).

Das Riesenproblem mit diesem CVS IMPORT ist, dass Binär-Dateien dadurch zerstört werden (z.B. GIF, JPG,...).

Wenn man das nicht alles in einem Rutsch tun möchte, kann man es auch einzeln Schritt für Schritt tun (s.u.).

Schritt 3: Ein leeres CVS-Modul erstellen

	mkdir xyz
	cd xyz
	cvs import rolodap LONZO V1_00
	cd ..
	rmdir xyz

Damit wird im CVS-Repository ein neues Modul names rolodap angelegt einschliesslich aller im Repository nötigen CVS-Files (z.B. .owner).

Nun muss ich für jedes CVS-Modul ein CVS-Arbeitsverzeichnis (sog. Sandbox) aufbauen mit "cvs checkout ...". Danach kann ich meinem CVS-Modul gezielt Dateien und Unterverzeichnisse (nur aus dem CVS-Arbeitsverzeichnis) mit "cvs add ..." hinzufügen.

Schritt 4: Eine CVS-Sandbox erstellen

	d:
	cd \home\kracht\www\dietrich.kracht.free.fr
	cvs checkout rolodap

Damit wird \home\kracht\www\dietrich.kracht.free.fr\rolodap eine CVS-Sandbox für das CVS-Modul "rolodap". Wir sehen das daran, dass ein verstecktes Unterverzeichnes namens "CVS" angelegt wurde.

Weil im CVS nicht mit "Locks" gearbeitet wird, benötigt jeder User ständig seine "Work Directories". In den versteckten CVS-Unterverzeichnissen jeder Sandbox speichert sich das CVS-System die nötige Verwaltungsinformation.

Der Verzeichnisname der CVS-Sandbox ist als identisch mit dem Modulnamen im CVS-Repository. Wenn man da besondere Wünsche für den Sandbox-Namen hat, muss man sich das schon beim Erstellen des CVS-Moduls überlegen.

Wenn die als Sandbox verwendeten Verzeichnisse nicht leer sind (macht man gerne am Anfang), erscheinen Warnmeldungen.

Schritt 5: Einzelne Inhalte der CVS-Sandbox ins CVS-Repository stellen

	d:
	cd \home\kracht\www\dietrich.kracht.free.fr\rolodap
	cvs add index.php			(ggf.  -b	für binary, oder gleich TortoiseCVS nehmen)
	cvs commit

Ebenso können Unterverzeichnisse der CVS-Sandbox in das CVS-Repository gestellt werden.
Wichtig im CVS: Eine CVS-Sandbox ist immer ein Ordner mit seiner Unterstruktur, wobei Teile der Sandbox ignoriert werden können. Ich mass also alles was zu meinem "Projekt" gehört, in so einer Sandbox unterbringen. Die CVS-Sandbox entspricht dann spiegelbildlich einem CVS-Modul.
Ich kann keine Dateien, die "neben" der CVS-Sandbox stehen in das CVS-Modul einchecken. Jedes "Projekt" muss also hierarchisch strukturiert sein!

Der cvs checkout arbeitet mit dem im Environment-Parameter "CVSROOT" eingestellten Repository. In diesem Falle ein privates CVS-Repository im lokalen Dateisystem meines Notebook-Computers. Genauso kann man sich aber auch ein CVS-Modul aus einem externen CVS-Repository holen:

	cvs -d:pserver:anoncvs@cvs.apache.org:/home/cvspublic checkout ant

-- Main.DietrichKracht - 16 May 2004