Versionsverwaltungen

Versionsverwaltungen Holger Jakobs bibjah@bg.bib.de, holger@jakobs.com 2006-01-13 Inhaltsverzeichnis 1 RCS 2 1.1 Das RCS-Verzeichnis.............................. 2 1.2 Erzeugen der ersten Version einer neuen Datei............... 2 1.3 Auschecken einer Version............................ 3 1.3.1 Auschecken einer Kopie........................ 3 1.3.2 Auschecken zum Ändern........................ 3 1.4 Bearbeiten und erneutes Einchecken...................... 4 1.5 Sonderfunktionen................................ 4 1.5.1 Versionsvergleich............................ 4 1.5.2 Auschecken einer früheren Version................... 5 1.5.3 Schlüsselwort-Ersetzung........................ 6 1.5.4 Die Entstehungsgeschichte einer Datei................ 6 2 CVS 7 2.1 Das CVS-Repository.............................. 8 2.2 Aufnehmen eines Projekts in CVS....................... 8 2.3 Auschecken eines Projekts........................... 9 2.4 Einchecken einer neuen Version........................ 9 2.5 Aktualisieren der eigenen Dateien....................... 10 2.6 Hinzufügen von Dateien............................ 10 2.7 Verzweigungen................................. 11 2.8 Sonderfunktionen................................ 11 2.8.1 Versionsvergleich............................ 11 2.8.2 Auschecken einer früheren Version................... 12 2.8.3 Sprung auf eine neue (Haupt-)Revision................ 13 2.8.4 Schlüsselwort-Ersetzung........................ 14 2.8.5 Löschen eines Projekts......................... 14 2.9 Weiterführendes................................. 14 3 Subversion 14 1

1 RCS 1 RCS Revision Control System Das Revision Control System (RCS) ist ein System zur Verwaltung von Versionen von ASCII-Dateien, meist Quelltexten. Mit Hilfe diese Systems ist es möglich, frühere Versionen von Dateien jederzeit wieder herzustellen. Darüber hinaus wird auch verhindert, dass verschiedene Personen gleichzeitig an der selben Datei Änderungen vornehmen. RCS ist sozusagen eine freie Variante von SCCS, dem Source Code Control System, das bei allen echten Unix-Systemen dabei ist, aber nicht als freie Software existiert. RCS gibt es sowohl auf kommerziellen Unixen als auch auf freien wie Linux und BSD und auch für Windows. Bei RCS muss eine Datei mit der Option -l ausgecheckt werden, um Änderungen vornehmen zu dürfen. Solange die Datei für einen bestimmten Benutzer ausgecheckt ist, darf kein anderer die Datei zum Ändern auschecken. Nur der Benutzer, der die Datei ausgecheckt hat, darf sie auch wieder einchecken überlicherweise mit einigen Änderungen. Die Sperren auf die Dateien sind nicht absolut, es ist also schon ein entsprechendes Verhalten der Team-Mitglieder notwendig. Sperren können auch entfernt werden, allerdings erhält der Benutzer, dessen Sperre entfernt wurde, eine Mail mit einer entsprechenden Mitteilung. Hinweis: Hier werden nur die Grundzüge des Systems erläutert. Für eine vollständige Erläuterung auch fortgeschrittener Optionen schauen Sie bitte in die man-pages des jeweiligen Kommandos. 1.1 Das RCS-Verzeichnis Man sollte im Verzeichnis, in dem Dateien mittels RCS verwaltet werden sollen, ein Unterverzeichnis namens RCS anlegen, damit die Versionsverwaltungsdateien nicht im aktuellen Verzeichnis herumliegen und Verwirrung stiften. Sobald ein solches Verzeichnis existiert, wird es von den RCS-Kommandos benutzt. 1.2 Erzeugen der ersten Version einer neuen Datei Nachdem man die erste Version einer Datei beispiel.c erzeugt hat, checkt man sie ein mittels ~> ci beispiel.c RCS/beispiel.c,v <-- beispiel.c enter description, terminated with single. or end of file: NOTE: This is NOT the log message! >>. initial revision: 1.1 2

1 RCS 1.3 Auschecken einer Version Es wird angezeigt, dass die Datei beispiel.c in der Versionsdatei RCS/beispiel.c,c abgelegt wird. Es wird nach einer Beschreibung gefragt, die durch eine Eingabe eines einzelnen Punktes auf einer Zeile beendet wird (ähnlich wie die Eingabe ins mail-kommando). Hier wurde nichts eingegeben, d. h. sofort ein Punkt eingegeben. Die Version ist die allererste (Initialversion), die üblicherweise die Nummer 1.1 trägt. Achtung: Es gibt niemals irgendwelche X.0-Versionen, sondern es wird immer mit 1 begonnen! Nun werden Sie feststellen, dass die Originaldatei weg ist. Benötigen Sie sie, z. B. um sie zu compilieren, dann müssen Sie sie wieder auschecken. 1.3 Auschecken einer Version Um eine Datei auszuchecken, verwendet man das Kommando co, wobei anzugeben ist, ob man nur eine Kopie haben möchte (an der man kein Schreibrecht bekommt) oder ob man die Datei bearbeiten und später wieder als neue Version einchecken möchte. 1.3.1 Auschecken einer Kopie Das Auschecken einer Kopie zu Compilationszwecken geschieht mit einfachem ~> co beispiel.c RCS/beispiel.c,v --> beispiel.c revision 1.1 ~>ll beispiel.c -r--r--r-- 1 fritz users 64 Feb 14 14:29 beispiel.c Hier bekommt der Anwender eine Datei ohne gesetzte Schreibrechte, so dass er sie nicht versehentlich überschreiben kann. 1.3.2 Auschecken zum Ändern Möchte man die Datei zur Bearbeitung auschecken, muss man die Option -l (l=lock, Sperre) verwenden. Dann hat man auch Schreibrechte. Hat man die Datei vorher als Kopie ausgecheckt, wird diese Datei (obwohl man eigentlich keine Schreibrechte darauf hat) ersetzt. ~> co -l beispiel.c RCS/beispiel.c,v --> beispiel.c revision 1.1 (locked) ~>ll beispiel.c -rw-r--r-- 1 fritz users 64 Feb 14 14:29 beispiel.c 3

1.4 Bearbeiten und erneutes Einchecken 1 RCS Andere Benutzer können diese Datei jetzt nicht mehr zur Änderung auschecken, aber sie können sie lesen, d. h. ohne Änderungsrecht auschecken. Die Zeit der gesetzten Sperre sollte man natürlich möglichst kurz halten. Stellt man fest, dass man doch keine Änderungen an der Datei vornehmen möchte, so kann man die Sperre mit folgendem Kommando wieder entfernen: ~> ci -u beispiel.c RCS/beispiel.c,v <-- beispiel.c file is unchanged; reverting to previous revision 1.1 1.4 Bearbeiten und erneutes Einchecken Nun nimmt man die gewünschten Änderunen an der Datei vor und checkt sie wieder ein. Es wird eine neue Version erzeugt, deren Nummer automatisch hochgezählt wird. ~> ci beispiel.c RCS/beispiel.c,v <-- beispiel.c new revision: 1.2; previous revision: 1.1 enter log message, terminated with single. or end of file: >>. Genau wie beim ersten Einchecken kann man auch hier einen Kommentar (log message) eingeben, so dass später nachvollzogen werden kann, aus welchem Grund die Änderung notwendig war bzw. was evtl. verbessert oder ergänzt wurde. 1.5 Sonderfunktionen Der übliche Gang der Dinge ist die kontinuierliche Weiterentwicklung einer Datei, so dass ständig neue Versionen eingecheckt werden. Gelegentlich kann es aber vorkommen, dass man auch auf ältere Versionen zurückgreifen muss oder möchte, dass man Versionen vergleichen will oder ähnliches. Noch einmal der Hinweis, dass hier nur ein Bruchteil der Möglichkeiten des RCS gezeigt wird, das Lesen der man-pages also unverzichtbar ist, wenn man über diese grundlegenden Funktionen hinaus mit RCS arbeiten will. 1.5.1 Versionsvergleich Zum Versionsvergleich verwendet man am besten ein Tool wie tkdiff 1, denn es checkt die zu vergleichenden Versionen automatisch in temporäre Dateien aus. Hat man ausgecheckt und etwas an der Datei geändert, kann man mit tkdiff die Änderungen sichtbar machen. 4

1 RCS 1.5 Sonderfunktionen Abbildung 1: Screenshot von tkdiff tkdiff wird mit dem Dateinamen als Parameter aufgerufen und vergleicht die Datei mit ihrer letzten eingecheckten Version. Das kann dann so aussehen wie in Abbildung 1. Ohne ein Tool wie tkdiff muss man manuell die alte Version auschecken und mit einem Tool wie diff (Standard-Unix-Tool) vergleichen. Das ist aber bei weitem nicht so komfortabel. Es gibt hierzu auch noch ein weiteres Tool rcsdiff, aber auch dies arbeitet nur auf der Kommandozeile. 1.5.2 Auschecken einer früheren Version Normalfall ist, dass beim Auschecken die aktuellste Version geholt wird. Möchte man aus irgendeinem Grund einmal auf einer ältere Version zurückgreifen, z. B. um diese als Softwarepröbchen zu verteilen oder daran noch Bugfixes (Korrekturen) vorzunehmen, ohne dem Kunden direkt die neueste Version zu geben, checkt mit mit der Option -r aus: ~> co -r1.2 beispiel.c RCS/beispiel.c,v --> beispiel.c revision 1.2 Auch frühere Versionen kann man mit -l zum Ändern auschecken, aber Vorsicht: Beim erneuten Einchecken wird ein neuer Zweig (branch) erzeugt, denn die Änderungen kann man ja nicht nachträglich in die normale Versionsfolge einbauen: 1) http://tkdiff.sf.net 5

1.5 Sonderfunktionen 1 RCS ~> ci beispiel.c RCS/beispiel.c,v <-- beispiel.c new revision: 1.2.1.1; previous revision: 1.2 enter log message, terminated with single. or end of file: >>. So kann es aussehen, wenn man von früheren Versionen neue Zweige erzeugt: 1.5.3 Schlüsselwort-Ersetzung RCS definiert eine ganze Reihe von Schlüsselwörtern (keywords), die beim Auschecken automatisch ersetzt werden. Diese dienen dazu, sowohl die Datei als auch die Version, die Autoren und weitere Informationen in den Quelltext einzutragen. Auf diese Weise kann man sich leicht eine garantiert fehlerfreie Anzeige der Programmversion (z. B. bei Aufruf des Programms mit der Option --version) einbauen. Um sie zu benutzen, muss man sie lediglich in den Quelltext eintragen z. B. in Kommentaren oder auch in der Initialisierung von Zeichenketten. Die Schlüsselwörter sind alle dadurch gekennzeichnet, dass sie zwischen Dollarzeichen geschrieben werden. Die gängigsten Schlüsselwörter sind in Tabelle 1 auf der nächsten Seite aufgeführt; weitere sehen in der man-page zu co). 1.5.4 Die Entstehungsgeschichte einer Datei Möchte man sich über die Entstehungsgeschichte einer Datei informieren und hat kein $Log: $ verwendet, so kann man sich doch die gesamte Geschichte erzählen lassen. Dazu gibt es das Kommando rlog: ~>rlog beispiel.c Es werden zunächst allgemeine Angaben gemacht wie die Nummer der neuesten Revision und die Beschreibung der Datei. Dann werden, jeweils durch eine Linie getrennt, die einzelnen Revisionen chronologisch rückwärts aufgeführt mit Revisionsnummer, Datum/ 6

2 CVS Tabelle 1: gängige RCS-Schlüsselwörter $Author: $ Benutzerkennung desjenigen, der die Version eingecheckt hat $Date: $ Datum/Zeit des Eincheckens $Header: $ alle wichtigen Informationen zusammen $Id: $ wie $Header: $, aber ohne absoluten Pfad $Log: $ die gesammelten Log-Meldungen, zu deren Eintragung man beim Einchecken jedes Mal aufgefordert wird Zeit, Benutzerkennung des Eincheckers, der Anzahl der hinzugekommen und entfernten Zeilen (gegenüber der vorigen Revision) sowie der Log-Message. Lesen Sie in der Originalliteratur nach, wenn Sie glauben, noch mehr solcher Funktionen zu benötigen. 2 CVS Concurrent Versions System CVS 2., das Concurrent Versions System, basierte früher auf RCS (siehe Abschnitt 1 auf Seite 2, kann aber mehr. Die über RCS hinausgehenden Eigenschaften sind hier skizziert. Es werden nicht mehr einzelne ASCII-Dateien, sondern ganze Verzeichnisse (sogenannte Projekte) verwaltet. Tatsächlich sind es sogar ganze Verzeichnisbäume, d. h. das Projekt kann aus mehreren Unterverzeichnissen bestehen. Es können mehrere Entwickler gleichzeitig ohne Aus- und Einchecken an Texten arbeiten. Es gibt keine Sperren mehr. CVS funktioniert auch über Netze, d. h. Entwicklergemeinschaften können über das Internet verbunden sein. Tatsächlich wird ein Großteil der Open-Source-Software von Entwicklergruppen erstellt, 2) Original-Hilfe unter http://www.bg.bib.de/portale/bes/progentwicklung/versionsverwaltung/uebercvs/cvs.html 7

2.1 Das CVS-Repository 2 CVS die nur über das Internet kommunizieren. Eine ständige Verbindung zum Internet ist übrigens nicht notwendig. Gerade der zweite Punkt klingt ziemlich nach Zauberei, basiert aber auf der Grundannahme, dass es bei einem Projekt Zuständigkeiten gibt und daher nicht mehrere Entwickler dieselben Stellen in den Quelltexten bearbeiten. CVS soll übrigens ausdrücklich nicht die Kommunikation zwischen Entwicklern ersetzen. Wenn Entwickler verantwortungsbewusst arbeiten, sind dann die Änderungen, die sie durchführen, üblicherweise disjunkt, d. h. sie sind unabhängig voneinander. Solche Änderungen können dann vollautomatisch zusammengeführt werden. Sollten doch einmal Konflikte auftreten, so müssen sie von den Beteiligten auf verantwortungsvolle Weise aufgelöst werden, was von einem Tool wie TkDiff 3 gut unterstützt wird, siehe auch Abbildung 1 auf Seite 5. 2.1 Das CVS-Repository Grundlage für das Arbeiten mit CVS ist das CVS-Repository, ein Speicherort (der auch im Netz sein darf), an dem alle erstellten Texte zentral gespeichert werden. Um damit arbeiten zu können, muss man eine Umgebungsvariable namens CVSROOT anlegen, die auf das Verzeichnis zeigt. Dieses Verzeichnis muss für alle Projektbeteiligten offen sein (rwx). Beispiel: export CVSROOT=$HOME/CVS-Wurzel Die Variable CVSROOT darf nicht direkt auf $HOME zeigen, sondern nur auf ein Verzeichnis darunter oder außerhalb davon. Um aus diesem Verzeichnis ein CVS-Repository zu machen, muss man einmal das Kommando cvs init eingeben. Es werden einige Dateien und Unterverzeichnisse erzeugt. 2.2 Aufnehmen eines Projekts in CVS Um ein Projekt unter die Verwaltung von CVS zu stellen, wechselt man ins Verzeichnis des Projekts und gibt folgendes Kommando ein: ~/projekt1> cvs import -m "Beispielprojekt" testprojekt beispiel start import ist das CVS-Kommando zum Importieren eines neuen Projekts. -m "..." steht für Logging Message, läßt man diese Option weg, so wird ein Editor (meist vi) geöffnet, um nach dieser Nachricht zu fragen. testprojekt ist der Name des Projekts, d. h. des Unterverzeichnisses, unter dem es im CVS-Repository gespeichert wird. Dieser Projektname muss eindeutig sein; es wird auch der Name des Verzeichnisses, in dem man sein Projekt lokal gespeichert hat. beispiel und start sind die Vendor und Release Tags, die bei einfachen Projekten keine weitere Bedeutung haben und hier nicht weiter erläutert werden sollen. CVS wird mit Importmeldungen für die importierten Dateien antworten. Diese bleiben aber im Gegensatz zu RCS im lokalen Verzeichnis erhalten und werden auch nicht gesperrt. 3) http://tkdiff.sf.net 8

2 CVS 2.3 Auschecken eines Projekts Das eingecheckte Verzeichnis kann man anschließend komplett löschen; es wird nicht mehr benötigt. Zum Arbeiten checkt man das Projekt unter Angabe seines Namens aus. Nun hat man ein unter der Verwaltung von CVS stehendes Verzeichnis mit demselben Namen wie das Projekt (erkennbar am Unterverzeichnis CVS, an dem man nicht fummeln sollte!). ~/projekt1> cd.. ~> cvs checkout testprojekt cvs checkout: Updating testprojekt U testprojekt/beispiel.c ~> cd testprojekt ~/testprojekt> ll insgesamt 2 drwxr-xr-x 2 benutzer users 1024 Feb 7 15:14 CVS -rw-r--r-- 1 benutzer users 210 Feb 7 14:42 beispiel.c Hier ist im Projekt nur eine Datei, beispiel.c, vorhanden. 2.3 Auschecken eines Projekts Möchte jetzt noch ein weiterer Entwickler am Projekt mitarbeiten, so holt er sich ebenfalls eine Kopie des Repository-Inhalts auf seinen Rechner bzw. in sein Verzeichnis mit ~> cvs checkout testprojekt Das erzeugt im aktuellen Verzeichnis ein Unterverzeichnis testprojekt mit allen vorher eingecheckten Dateien und einem Unterverzeichnis CVS, das man tunlichst nicht verändert. Dieses Auschecken können natürlich beliebig viele Entwickler tun. An den ausgecheckten Dateien können nun Änderungen vorgenommen werden, wobei man sich mit den anderen Entwicklern absprechen sollte rein organisatorisch, nicht technisch. 2.4 Einchecken einer neuen Version Nach Weiterentwicklung und Austesten sollte man die eigenen Ergebnisse ins zentrale Repository zurückchecken. Dies kann jeder der Entwickler jederzeit tun. /testprojekt> cvs commit -m "Superverbesserung" Es werden Änderungen an allen Dateien des Projekts zurückgespielt. Voraussetzung ist, dass kein anderer Entwickler zwischenzeitlich Änderungen an denselben Dateien vorgenommen hatte, denn das würde dazu führen, dass man die Änderungen erst in seinen eigenen Arbeitsbereich überführen müsste, um eventuelle Konflikte aufzuspüren und diese aufzulösen. Wenn gemeckert wird, aktualisiert man also zuerst mit cvs update (siehe Abschnitt 2.5 auf der nächsten Seite) und löst ggf. vorhandene Konflikte auf. 9

2.5 Aktualisieren der eigenen Dateien 2 CVS 2.5 Aktualisieren der eigenen Dateien Um Änderungen, die andere Entwickler gemacht haben, ins eigene Verzeichnis zu übernehmen, verwendet man ~/testprojekt> cvs update In den meisten Fällen wird das Zusammenführen der Änderungen (merge) automatisch durchgeführt. Aber auch hier können Konflikte auftreten, die dann in den jeweiligen Quelltexten markiert werden, so dass sie mit einem gewöhnlichen Editor bearbeitet werden können. Bequemer geht das Auflösen der Konflikte aber mit einem Tool wie TkDiff 4, siehe auch Abbildung 1 auf Seite 5. So sieht eine Meldung aus, wenn es Konflikte gibt: Merging differences between 1.1.1.1 and 1.2 into foo.c rcsmerge: warning: conflicts during merge cvs update: conflicts found in foo.c C foo.c In der Datei sieht der Vermerk des Konflikt so aus: void foo() { printf("foo\n"); <<<<<<< foo.c printf("too\n"); ======= printf("you\n"); >>>>>>> 1.2 } Hier muss man sich also zwischen TOO und YOU entscheiden und die überzähligen Zeilen löschen. Wenn die Konflikte aufgelöst sind, kann man konfliktfrei und damit erfolgreich seine eigenen Änderungen wieder ins zentrale Repository zurückspielen. 2.6 Hinzufügen von Dateien Ein Projekt wächst, d. h. die bei Projektbeginn eingecheckte Anzahl von Dateien wird sich verändern. Um eine neue Datei ins Projekt aufzunehmen, erzeugt man diese ganz normal und fügt sie dann hinzu mittels ~/testprojekt> cvs add dateiname Beim nächsten commit wird die Datei dann allen anderen Entwicklern zur Verfügung gestellt. 4) http://tkdiff.sf.net 10

2 CVS 2.7 Verzweigungen 2.7 Verzweigungen Auch in CVS kann man wie in RCS und SCCS Zweige erstellen, um abgewandelte Versionen eines Projekts zu erstellen. Das geht aber über die absoluten Grundlagen hinaus und soll hier nicht weiter erläutert werden. 2.8 Sonderfunktionen Der übliche Gang der Dinge ist die kontinuierliche Weiterentwicklung einer Datei, so dass ständig neue Versionen eingecheckt werden. Gelegentlich kann es aber vorkommen, dass man auch auf ältere Versionen zurückgreifen muss oder möchte, dass man Versionen vergleichen will oder ähnliches. Noch einmal der Hinweis, dass hier nur ein Bruchteil der Möglichkeiten des CVS gezeigt wird, das Lesen der man-pages also unverzichtbar ist, wenn man über diese grundlegenden Funktionen hinaus mit CVS arbeiten will. 2.8.1 Versionsvergleich Zum Versionsvergleich verwendet man am besten ein Tool wie tkdiff 5 (siehe auch Abbildung 1 auf Seite 5), denn es checkt die zu vergleichenden Versionen automatisch in temporäre Dateien aus. Hat man ausgecheckt und etwas an der Datei geändert, kann man mit tkdiff die Änderungen sichtbar machen. tkdiff wird mit dem Dateinamen als Parameter aufgerufen und vergleicht die Datei mit ihrer letzten eingecheckten Version. Das kann dann so aussehen wie in Abbildung 2 auf der nächsten Seite CVS selbst ist dazu auch in der Lage, aber arbeitet nur auf der Kommandozeile: ~/testprojekt> cvs diff beispiel.c Index: beispiel.c =================================================================== RCS file: /home/.../testprojekt/beispiel.c,v retrieving revision 1.2 diff -r1.2 beispiel.c 5,6c5,7 < puts ("Oh what a wonderful day."); < return 0 --- > puts ("O was für ein wunderbarer Tag."); > puts ("Vielen Dank fürs Gespräch!") > return 0; 5) http://tkdiff.sf.net 11

2.8 Sonderfunktionen 2 CVS Abbildung 2: TkDiff-Screenshot mit CVS 2.8.2 Auschecken einer früheren Version Normalfall ist, dass beim Auschecken die aktuellste Version geholt wird. Möchte man aus irgendeinem Grund einmal auf einer ältere Version zurückgreifen, z. B. um diese als Softwarepröbchen zu verteilen oder daran noch Bugfixes (Korrekturen) vorzunehmen, ohne dem Kunden direkt die neueste Version zu geben, so kann man das bei CVS nicht basierend auf den Revisionsnummern der einzelnen Dateien machen was bei größeren Projekten auch kaum noch handhabbar wäre, sondern muss hier einen Zeitpunkt oder einen symbolischen Revisionsnamen angeben. Das von RCS bekannte Verfahren mit den Revisionsnummern funktioniert dann, wenn man zusätzlich nur eine einzelne Datei angibt, die man aktualiseren möchte: ~/testprojekt> cvs update -p -r 1.3 beispiel.c Diese symbolischen Revisionsnamen vergibt man immer dann, wenn man einen Stand erreicht hat, in dem man das Produkt ausliefern möchte, d. h. nach allen notwendigen Tests, aber vor der Produktion der Installationsdatenträger. Hierzu tag t man alle Dateien eines Projekts (to tag=markieren) und kann diesen Stand dann später unter Angabe des Tags ; (in einem anderen Verzeichnis!) wieder auschecken. Auf diese Art und Weise wird ein symbolischer Name für das Gesamtprojekt festgelegt, statt eine Revisionsnummer nur für eine einzelne Datei zu verwenden. ~/testprojekt> cvs tag "Version_1a" 12

2 CVS 2.8 Sonderfunktionen cvs tag: Tagging. T beispiel.c ~/testprojekt> echo "nach Version 1a" >> beispiel.c ~/testprojekt> cvs commit cvs commit: Examining. Log message unchanged or not specified a)bort, c)ontinue, e)dit,!)reuse this message unchanged for remaining dirs Action: (continue) Checking in beispiel.c; /home/.../testprojekt/beispiel.c,v <-- beispiel.c new revision: 1.3; previous revision: 1.2 ~/testprojekt > cd.. ~> mkdir alt ~> cd alt ~/alt> cvs checkout -r Version_1a testprojekt cvs checkout: Updating testprojekt U testprojekt/beispiel.c ~/alt> cd testprojekt ~/alt/testprojekt > cat beispiel.c #include <stdio.h> int main () { puts ("Hallo Welt, o was für ein wunderbarer Morgen!"); puts ("Oh what a wonderful day."); return 0 } Wie man sieht, enthält die ins Verzeichnis alt/testprojekt ausgecheckte Version nicht den mittels echo angefügten Text, obwohl die Ergänzung committet wurde. Möchte man basierend auf einer Version einen neuen Zweig beginnen, dann muss man beim Taggen die Option -b (für branch = Zweig) mit angeben. Vielleicht ist es aber besser, das Verzeichnis dann unter einem anderen Namen komplett neu einzuchecken, um es gänzlich unabhängig vom Originalprojekt zu machen. 2.8.3 Sprung auf eine neue (Haupt-)Revision Gelegentlich möchte man eine neue Haupt-Revisionsnummer beginnen. Dazu gibt man diese neue Revisionsnummer beim cvs commit mit an. Hierbei werden alle Dateien (auch die unveränderten) auf diese neue Revisionsnummer hochgesetzt: ~/testprojekt> cvs commit -r2.1 13

2.9 Weiterführendes 3 SUBVERSION 2.8.4 Schlüsselwort-Ersetzung Die Schlüsselwort-Ersetzung funktioniert genau wie bei RCS und ist in Abschnitt 1.5.2 auf Seite 6 erklärt. 2.8.5 Löschen eines Projekts Möchte man ein ganzes Projekt (CVS-Modul) löschen, z. B. weil man ein falsches Verzeichnis importiert hat oder ein Projekt endgültig gestorben ist, so kann man das nicht mit den CVS-Kommandos machen. Wohl aber kann man in das CVSROOT-Verzeichnis wechseln und ein rekursives rm (Vorsicht!) ausführen. Andere Projekte werden davon nicht betroffen. 2.9 Weiterführendes Lesen Sie in der Originalliteratur nach, wenn Sie glauben, noch mehr solcher Sonderfunktionen zu benötigen. Das ist z. B. die man-page, die allerdings etwas unübersichtlich ist, oder aber eine der vielen Quellen im WWW zum Thema CVS. Zu CVS gibt es auch grafische Frontends, z. B. http://www.twobarleycorns.net/tkcvs.html TkCVS, das übrigens TkDiff schon enthält. Eine weitere Literaturempfehlung: http://cvsbook.red-bean.com/cvsbook.html http://www.csc.calpoly.edu/ dbutler/tutorials/winter96/cvs/ noch ein Tutorial zum Thema CVS. Zu CVS gibt es übrigens mehrere grafische Front-Ends, eines davon, TkCVS, wird auf der Seite http://www.bg.bib.de/"portale/bes/progentwicklung/versionsverwaltung/uebertkcvs/ ausführlich vorgestellt. 3 Subversion Subversion 6 wird als Nachfolger von CVS gehandelt, d. h. es ist von den Entwicklern beabsichtigt, CVS zu ersetzen. Die Bedienung ist der von CVS sehr ähnlich, um den Umstieg zu erleichtern. Auch gibt es Tools, um vorhandene Projekte (Repositories) von CVS auf Subversion zu übertragen, ohne die Historie zu verlieren. Eines davon heißt cvs2svn 7. In den Kommandos zum Ein- und Auschecken ist lediglich cvs durch svn zu ersetzen. Auf diese Weise ist auch die Integration in Entwicklungsumgebungen ganz leicht zu bewerkstelligen. Evtl. kann man sogar einfach einen Alias setzen, der aus allen cvs-aufrufen dann 6) http://subversion.tigris.org 7) http://cvs2svn.tigris.org 14

3 SUBVERSION svn-aufrufe macht. Um wirklich cvs aufzurufen, müsste man es dann mit Pfad aufrufen oder den Alias temporär löschen. Subversion unterliegt wie Subversion einer OpenSource-Lizenz, und zwar einer Apache/ BSD-Lizenz. Es werden Binärversionen für alle gängigen Betriebssysteme angeboten. Die Server gibt es allerdings nicht für die alten, DOS-basierten Windows-Versionen, sondern erst von NT an aufwärts. Die Clients gibt es auch für Win9x/ME. Genau wie für CVS gibt es auch für Subversion diverse grafische und auch Web-Clients, u. a. unterstützt TkCVS 8 ab Version 8 auch Subversion. Vorteile gegenüber CVS soll Subversion insbesondere bei diesen Punkten bringen: Dateien können leichter umbenannt und/oder verschoben werden, ohne dass die Historie verloren geht. Der Umgang mit Binärdateien ist besser. Commit-Vorgänge sind atomar, d. h. auch bei einem Abbrechen der Verbindung zum Server kann es keine Inkonsistenzen geben. Es werden beim Commit weniger Daten übertragen (nur die geänderten Zeilen, nicht die ganzen Dateien). Bei langsamen Leitungen ist es schneller (bei manchen Operationen aber auch langsamer). Nachteile gibt es natürlich auch: Das Repository braucht mehr Platz auf der Platte als bei CVS. Ob die Stabilität schon so gut ist wie beim rund 20 Jahre gereiften CVS, gilt als unsicher. Es werden mehr andere Softwarepakte vorausgesetzt, z. B. die Apache Portable Runtime. Auch CVS entwickelt sich noch weiter, so dass die Zukunft zeigen wird, ob CVS längerfristig komplett von Subversion abgelöst wird. Als sicher kann das noch nicht gesehen werden. Wenn man derzeit ein neues Projekt anfängt, ist man in der Entscheidung ziemlich frei, denn ein Umstieg von CVS nach Subversion ist dank der Konversionstools relativ einfach. Ob es auch umgekehrt möglich ist, falls man doch mal zurück will? $Id: rcs-cvs.tex,v 1.7 2006/01/13 11:30:53 hj Exp $ 8) http://www.twobarleycorns.net/tkcvs.html 15