| E-Mail: |  prilmeie@in.tum.de |
|---|---|
| Homepage-URL: |  http://home.in.tum.de/prilmeie/ |
Bei Fragen zu diesem Beitrag bitte den Autor des Beitrags kontaktieren!
Jedes ernsthafte Projekt bedarf Regelungen zur Verwaltung von Quelltexten und zur Qualitätssicherung. Das gilt nicht nur für Softwareprojekte, sondern auch für Web-Projekte. Versionskontrollsysteme liefern einem genau die richtigen Werkzeuge für diese Aufgaben. Sie ermöglichen den Zugriff auf die aktuelle oder auch auf frühere Versionen der Quelltexte. Man könnte natürlich alle früheren Versionen einfach sichern, ein Versionskontrollsystem ist jedoch bei der Speicherung in jedem Falle effizienter.
Bei Projekten die von mehreren Mitarbeitern bearbeitet werden, bieten Versionskontrollsysteme meist die einzige sinnvolle Möglichkeit das Projekt bei räumlicher Verteilung der Mitarbeiter sinnvoll zu organisieren. Bearbeiten z.B. zwei Mitarbeiter eine Datei gleichzeitig, dann verliert derjenige seine Arbeit, der die Datei zuerst zurückschreibt. Die Aufgabe eines Versionskontrollsystems ist es genau dieser Situation entgegenzuwirken; Jeder Mitarbeiter erhält dazu seine eigene Arbeitskopie. Falls er seine Arbeit beendet hat, dann signalisiert er dies dem Versionskontrollsystem. Dieses nimmt dann die Änderungen auf und trägt diese anschliessend in den bereits vorhandenen Dateien ein. Würde dabei die Arbeit eines anderen Mitarbeiters überschrieben werden, so wird das Versionskontrollsystem entsprechende Maßnahmen einleiten.
Zusammenfassend kann man sagen, Versionskontrolle wird immer dann benötigt, wenn
Das bekannteste der freien Versionskontrollsysteme ist das Concurrent Version System (CVS).
Im Folgenden lernen wir kurz die Grundfunktionen kennen, mehr Auskünfte gibt aber auf
jeden Fall das offizielle
Manual von CVS. CVS ist für verschiedene
Plattformen erhältlich, unter anderem für MS-Windows, Linux und den meisten Unix Derivaten,
inklusive dem Quellcode. Eine Übersicht der erhältlichen Platformen kann man sich bei der
bei der Downloadseite von CVS verschaffen.
CVS speichert alle Dateien an einem zentralen Platz, dem sogenannten Repository. Der erste Schritt ist also so ein Repository einzurichten. Davor muss man sich allerdings zuerst über die Lage des Wurzelverzeichnis des Repository, dem sogenannten CVSROOT, klar werden. Hat man ein derartiges Verzeichnis festgelegt, dann kann man das Repository anlegen. Dazu öffnet man eine Eingabeauforderung (bzw. Shell) und gibt folgenden Befehl ein:
cvs -d CVSROOT init
An sich müsste man für jeden cvs Befehl immer -d CVSROOT angeben.
Dies kann man vermeiden, falls man eine Umgebungsvariable CVSROOT setzt. In einer MS-Windows
Eingabeaufforderung setzt man Umgebungsvariablen entweder in der Datei autoexec.bat
(Dazu ist aber ein Neustart erforderlich) oder in der Eingabeaufforderung mit dem Befehl
set CVSROOT=<CVSROOT>, wobei für <CVSROOT> das gewählte
Verzeichnis einzusetzen ist. Für andere Betriebssysteme gibt es ähnliche Vorgehensweisen.
Ist einmal die Variable CVSROOT gesetzt, dann kann man sich die zusätzliche Angabe dazu sparen.
Da nun das Repository eingerichtet ist, können wir das erste Projekt importieren. Nennen wir das Projekt der Einfachheit halber einfach "Projekt". Dann kann man das leere Projekt "Projekt" wie folgt in CVS importieren:
| Eingabe | Bedeutung |
|---|---|
mkdir Project |
Das Verzeichnis "Projekt" anlegen. |
cd Projekt |
Ins Verzeichnis "Projekt" wechseln. |
cvs import -m "Nachricht" Projekt Firmenname Ausgabezusatz |
Das Projekt importieren. |
Der letzte Befehl bedarf etwas Erläuterung. Der Befehl import
dürfte klar sein, damit zeigen wir dem System an, dass wir etwas importieren wollen. An
der nächsten Stelle kommt mit der Angabe -m "Nachricht" ein sehr
wichtiges Merkmal, denn man kann bei jeder Änderung dem System mitteilen, was man
geändert hat. Damit können Entwickler sich z.B. untereinander mitteilen, was
sie gerade geändert haben. Diese Aufgabe kann ein Versionskontrollsystem den Entwicklern
nicht abnehmen, es zwingt jedoch Entwickler diese Angaben zu machen, denn ohne Nachricht wird das
System den Befehl nicht akzeptieren. Mit Projekt gibt man dem System bekannt, unter
welchen Namen das Projekt abgespeichert werden soll. Basierend auf dieser Angabe erzeugt das System
intern eine Verzeichisstruktur, die beim Austragen (checkout) wieder nachgebildet wird.
Im Beispiel oben wurde als Projektname "Projekt" angegeben. Es dürfte klar sein, dass
der Name eines Projektes im System eindeutig sein muss, d.h. es darf kein weiteres Projekt mit
demselben Namen geben. Die Angaben über Firmennamen und Ausgabezusatz
haben in diesem Zusammenhang keine Bedeutung, CVS verlangt aber die Angabe dieser beiden Atribute.
Sie sind vor allem im Zusammenhang mit Programmen und Arbeiten Dritter von Bedeutung.
Nachdem wir nun also unser erstes Projekt importiert haben, wollen wir es auch gleich wieder austragen, um daran arbeiten zu können:
cvs checkout Projekt
Nun müsste ein Verzeichnis "Projekt" entstanden sein. Interessant ist, dass sich in diesem Verzeichnis ein Unterverzeichnis CVS befindet. In diesem Verzeichnis sind Informationen zu dem aktuellen Verzeichnis gespeichert. Diese Informationen sind für das CVS System wichtig und sollten nicht besonders stören. Jetzt können wir mit der Arbeit beginnen. Zuerst erstellen wir eine Webseite, nennen wir sie index.html und ein passendes Bild, nennen wir es title.gif. Anschliessend teilen wir dem System mit, dass wir die beiden Dateien zum Projekt hinzufügen möchten:
| Eingabe | Bedeutung |
|---|---|
cvs add -m "Das ist meine erste Webseite" index.html |
Die Datei index.html hinzufügen. Da wir uns ja bereits im Verzeichnis "Projekt" befinden, ist eine Angabe des Verzeichnisses nicht notwendig. |
cvs add -kb -m "Das passende Bild dazu" title.gif |
Die Datei title.gif hinzufügen. Da ein Bild für das CVS System Binärdaten darstellt, muss dies dem System mittels -kb mitgeteilt werden. |
cvs commit -m "Bild und Webseite hinzugefügt" index.html title.gif |
Erst der Befehl commit fügt die Dateien in das Repository ein. |
Der Befehl commit wird immer dann benutzt, wenn Änderungen im Repository
vorgenommen werden sollen. Das System weisst dann den geänderten Dateien eine
höhere Versionsnummer zu.
Falls nun mehrere Entwickler an dem Projekt arbeiten, dann ist es notwendig sich ab und
zu die Änderungen, die in der Zwischenzeit gemacht wurden, zu holen. Dafür gibt
es den Befehl update:
cvs update Projekt
Dann werden alle Änderungen in die Arbeitskopie übernommen. Normalerweise geht soetwas problemlos vonstatten, wurden jedoch Änderungen gemacht, die nahe bei Änderungen liegen, die wir selbst eingefügt haben, dann gibt es einen Konflikt. CVS wird die betreffenden Stellen markieren und wir müssen dafür Sorge tragen, dass wir diesen Konflikt selbst auflösen. Damit wir nicht in eine solche Situation geraten, ist Absprache zwischen den Beteiligten unbedingt erforderlich. Das System zwingt uns zudem zu einem Update, falls wir versuchen sollten eine veränderte Datei einzutragen, die im Repository in einer höheren Version vorliegt als die, die wir bearbeitet haben.
Mitten im Projektablauf entscheiden wir uns dazu das Bild wieder zu entfernen, da es nicht
mehr ins Projekt passt. Dafür verwendet man den Befehl remove:
| Eingabe | Bedeutung |
|---|---|
del title.gif |
Die Datei title.gif in der Arbeitskopie löschen. Falls wir uns anders entscheiden sollten, dann lässt sich die Datei mit update wieder herstellen. |
cvs remove -m "Das Bild passt nicht mehr ins Konzept" title.gif |
Dem System mitteilen, dass wir die Datei title.gif löschen wollen. Falls wir uns doch noch umentscheiden sollten, dann kann man dies mit dem entsprechenden add Befehl wieder rückgängig machen. |
cvs commit -m "Bild entfernt" title.gif |
Erst der Befehl commit löscht die Datei im Repository. Die Datei wird dann im Repository als gelöscht markiert, d.h. sie fehlt ab jetzt im aktuellen Projekt. |
Angenommen, eine Änderung in der Datei index.html hat einen Fehler zur Folge.
Man kann sich nun mühsam durch die Datei kämpfen, oder man lässt sich vom
Versionskontrollsystem die Änderungen in der Datei anzeigen. Auf diese Weise wird der Suchkreis
für den Fehler stark verkleinert. Der zugehörige Befehl heisst diff:
| Eingabe | Bedeutung |
|---|---|
cvs diff index.html |
CVS soll unsere lokale Kopie von index.html mit der Version vergleichen, die wir ausgetragen haben. |
cvs diff -r <Version> index.html |
CVS soll unsere lokale Kopie von index.html mit der Version vergleichen, die wir mit <Version> angegeben haben. |
cvs checkout -r <Version> index.html |
Mit diesem Befehl tragen wir die Version <Version> der Datei index.html aus. |
Haben wir unsere Arbeit beendet und unsere Änderungen sind eingetragen, so
können wir unsere Arbeitskopie wieder löschen. Der zugehörige
Befehl heisst release:
| Eingabe | Bedeutung |
|---|---|
cd .. |
Ein Verzeichnis höher wechseln. |
cvs release -d Projekt |
CVS untersucht unser Arbeitsverzeichnis, ob wir nicht doch vergessen haben etwas einzutragen. Nur wenn wir alle Veränderungen ins Repository eingetragen haben, wird das System das Verzeichnis Projekt löschen. |
Wir hätten das Verzeichnis auch einfach löschen können, aber release
ist in der Hinsicht einfach besser, da wir kein schlechtes Gewissen haben brauchen, ob wir nicht
etwas vergessen haben. Wir erreichen damit das Ende der Einführung in die Grundfunktionen von
CVS. Für das alltägliche Arbeiten mit CVS dürften diese eigentlich ausreichen.
Concurrent Version System (CVS) Homepage
CVS kann man auch über das Internet benutzen, es unterstützt sogar
Verschlüsselung mittels
SSH, was
bei Projekten, bei denen Geld oder Konkurrenz im Spiel ist, auch dringend angebracht ist.
Liegt das Repository nicht auf dem eigenen Rechner, sondern ist über das Inter- bzw. Intranet erreichbar, so macht das nur an einer Stelle einen Unterschied, nämlich beim CVSROOT. Dieser muss nun auf den entfernten Rechner gesetzt sein. Das Format ist im allgemeinen:
:Methode:benutzername@rechnername:/Pfad/zum/Repository
Nehmen wir also an, der Rechner heisst cvs.beispiel.de, unser Benutzername wäre
meier und das Repository liegt im Verzeichnis (Achtung, UNIX) /usr/cvsroot.
Wir wollen wieder das Projekt "Projekt" austragen. Im ersten Versuch sind
wir mal unvorsichtig und benutzen als Methode passwd. Das wird allerdings nur funktionieren,
falls auf cvs.beispiel.de ein CVS Server läuft und wir auch einen gültigen
Zugang zum Rechner cvs.beispiel.de haben:
| Eingabe | Bedeutung |
|---|---|
cvs -d :passwd:meier@cvs.beispiel.de:/usr/cvsroot login |
Beim Rechner cvs.beispiel.de anmelden. |
CVS password: |
Das Passwort übermitteln. Hier ist zu beachten, dass man blind tippt, d.h. man sieht seine Eingabe nicht (die Eingabe wird nicht einmal durch * maskiert). |
cvs -d :passwd:meier@cvs.beispiel.de:/usr/cvsroot checkout Projekt |
Wie gewohnt das "Projekt" austragen. |
Da wir aber wissen, dass auf diese Weise Passwörter und unsere Projektdateien im
Klartext übertragen werden (d.h. unser Konkurrent kann unter Umständen diese
Dateien mitlesen), verlassen wir uns lieber auf starke Verschlüsselung, in diesem
Falle SSH.
Wir nehmen an, cvs.beispiel.de ist ein UNIX - basierter Rechner, und auf diesem
Rechner ist ein SSH Server am Laufen. Natürlich müssen
wir ein existierender Benutzer des Rechners sein. Wir werden jetzt mit einer
SSH Verbindung das Projekt "Projekt" austragen.
Wir werden dies auf einem Rechner mit MS-Windows als Platform durchführen.
Als SSH werden wir
PuTTY verwenden, das ist eine
freie SSH-Software. Unabdingbar ist natürlich eine Vorhandene Installation
von CVS auf unserem MS-Windows Rechner mit gesetztem Pfad (d.h. in der Kommandozeile genügt es,
wenn man cvs eingibt).
Unser erster Schritt ist es, dass wir uns ohne Passwort auf dem Rechner cvs.beispiel.de anmelden können, dazu benötigen wir eine sogenannte RSA identity. Wir melden uns dazu mit Hilfe des Programmes putty.exe auf dem Rechner cvs.beispiel.de an. Wichtig ist dabei, dass wir als Protokoll SSH verwenden und nicht Telnet. Wir geben also in das Feld "Host Name" cvs.beispiel.de ein, und aktivieren den "SSH" Radiobutton. Nun können wir die Angaben mit dem Knopf "Open" bestätigen. PuTTY frägt uns dann, ob wir den Schlüssel des Rechners cvs.beispiel.de akzeptieren und ob der Schlüssel gespeichert werden soll, wir klicken auf "ja". Wenn wir nach Eingabe unseres Passwortes am System angemeldet sind und eine Kommandoeingabeaufforderung erscheint, dann geben wir folgende Befehle ein:
| Eingabe | Bedeutung |
|---|---|
ssh-keygen |
Ein Schlüsselpaar erzeugen. Einer der beiden Schlüssel wird später zu unserer Identität. |
Enter file in which to save the key (~/.ssh/identity): |
Den Ort, wo das Schlüsselpaar abgespeichert werden soll angeben. Der vorgeschlagene Ort sollte verwendet werden. |
Enter passphrase (empty for no passphrase): |
Ein sicheres Passwort für unseren Schlüssel angeben. Achtung, hier tippt man wieder blind, man sieht also seine Eingabe nicht. Allerdings muss man das Passwort anschliessend gleich wieder verifizieren, es ist also sehr unwahrscheinlich, dass man hier ein falsches Passwort eingibt. |
cd .ssh |
Ins Verzeichnis .ssh wechseln. |
mv identity.pub authorized_keys |
Der private Schlüssel identity kann ab jetzt als Identität zum Anmelden beim Rechner cvs.beispiel.de verwendet werden. |
Anschliessend kann man sich wieder abmelden. Nun muss der private Teil des Schlüssels,
identity auf den Rechner mit MS-Windows importiert werden. Dazu verwenden wir das
Programm pscp.exe. Nehmen wir wieder an, unser Name wäre meier, und
unser Heimatverzeichnis auf dem Rechner cvs.beispiel.de wäre /home/meier.
Dann importieren wir den Schlüssel nach C:\temp\identity mit
folgendem Befehl:
pscp meier@cvs.beispiel.de:/home/meier/.ssh/identity c:\temp\identity
Diesen Teil des Schlüssel bewahren wir gut auf, denn er ist so eine Art Ausweis für den Rechner cvs.beispiel.de. Deshalb nennt man diesen Teil des Schlüsselpaares auch den privaten Teil. Auf keinen Fall dürfen Dritte Zugang zu diesem Schlüssel erhalten.
Wir starten jetzt pageant.exe. Ein Computer mit einem Hut dürfte bei der Uhr
(im sogenannten SysTray) erscheinen. Mittels des Menüpunktes Add Key importieren
wir den privaten Schlüssel in pageant.exe. Das Programm wird uns nach einem Passwort
fragen. Hier muss man das Passwort eingeben, dass man bei der Erzeugung des Schlüsselpaares
benutzt hat. Diesen Schritt muss man im Gegensatz zu den anderen Schritten beim Neustart von Windows
immer wiederholen. Dies ist im Übrigen keine Schikane, sondern ein Beitrag zur Sicherheit, denn
es könnte auch jemand anderes als wir den Computer benutzen und somit Zugriff zu unserer
Identität erhalten. Ohne Passwort ist unsere Identität so gut wie nutzlos.
Bevor wir uns jetzt wirklich in Sicherheit wägen können müssen wir noch ein paar Variablen auf der Komandozeile setzen:
| Variable | Wert |
|---|---|
CVS_RSH |
Diese Variable müssen wir auf den Pfad zum Programm plink.exe setzen. |
CVS_SERVER |
Diese Variable müssen man auf das Programm cvs auf dem Rechner cvs.beispiel.de setzen. Den Wert erhalten wir mit Hilfe des Befehls which cvs (Natürlich müssen wir den Befehl auf dem Rechner cvs.beispiel.de ausführen). |
Nun können wir getrost CVS benutzen, ohne uns Sorgen um unsere Daten oder Passwörter zu machen:
cvs -d :ext:meier@cvs.beispiel.de:/usr/cvsroot checkout Projekt
Zu beachten ist, dass wir als Methode ext und nicht mehr passwd benutzen.
Auf die Dauer ist natürlich die Arbeit mit der Kommandozeile etwas nervend, besonders bei
tief verschachtelten Verzeichnisstrukturen. Abhilfe bieten einem hier
Benutzeroberflächen, die die
Funktionalität hinter Menüs und Buttons verstecken.
CvsGui
Benutzeroberflächen für CVS
Weitere Informationen zu CVS findet man im
Manual, in der Mailingliste info-cvs, bei
der man sich mit einer Mail an info-cvs-request@gnu.org eintragen lassen kann oder in der
Newsgruppe comp.software.config-mgmt.
Neben CVS gibt es noch weitere Versionskontrollsysteme. Die Auswahl erhebt natürlich keinen Anspruch auf Vollständigkeit. Der Autor kann und wird keinen Support bei den genannten Systemen leisten.
Kommerzielle Versionskontrollsysteme:
Microsoft VisualSourceSafe Perforce Revision Control Engine (RCE) TRUEchangeFreie Versionskontrollsysteme:
Siehe auch:
Überblick über Versionskontrollsysteme
Dies ist ein FAQ Artikel der Newsgruppe
comp.software.config-mgmt, die sich mit
Versionskontrollsystemen beschäftigt.
