an Hand eines Beispiels Konsole

Transkript

1 Versionskontrolle an Hand eines Beispiels Konsole 1 / 14 PAUL SCHEREMET

2 Inhaltsverzeichnis Einleitung 3 Das Repository anlegen (init) 4 Das erste Modul importieren (import) 5 Module auschecken (checkout / co) 6 Module einchecken (commit) 7 Dateien zu einem Modul hinzufügen (add & commit) 8 Datei aus einem Modul entfernen(remove & commit) 9 Änderungen zum Repository anzeigen 10 Konflikte beim Einchecken 11 Konflikte lösen 11 Gewisse Dateien nicht versionieren (.cvsignore) 12 In der History zurück gehen 13 Quellenangaben 14 2 / 14 PAUL SCHEREMET

3 Einleitung Wer im Team an einem Projekt arbeitet, mit mehreren Rechnern zu tun hat, an großen Projekten beteiligt ist, oder gar alles auf einmal, wird nur in wenigen Fällen das direkte Arbeiten am Quellcode als die wahre Lösung ansehen. In aller Regel startet das Projekt mit einem kleinen Verzeichnisbaum, der dann die Grundlage bildet. Diesen Verzeichnisbaum hegen und pflegen zulernen ist Ziel dieses kleinen Tutorials. Auch wenn ihr das nicht auf uranus2.fh-weingarten.de machen sollt, schildere ich den Ablauf mal so, als wär dieser Server der Garten eures Verzeichnisbaums (später sagen wir zum Garten Host und zum Verzeichnis baum Repository) CVS IST AUF URANUS2.FH-WEINGARTEN.DE NICHT EINGERICHTET UND SOLLTE DAHER DARAUF AUCH NICHT VERWENDET WERDEN! Solltet ihr irgendeinen anderen Server der FH benutzen wollen, denkt daran, dass ihr dafür entsprechende Tunnel graben müsst, da seit April 2005 SSH nur noch über besagten Server von Zuhause aus funktioniert. Am besten, ihr fragt einen Kommilitone, ob er einen privaten Server hat, o.ä. und packts dort drauf. Viel Spaß und Erfolg im Projekt, Paul Scheremet 3 / 14 PAUL SCHEREMET

4 Das Repository anlegen (init) Meldet euch auf dem Server an einer (SSH-)Konsole an. Mit Hilfe der folgenden Befehle wird der Pfad für das Repository erzeugt: > cd ; cd PUB/Stud/Stud/sysop/ > ls Gruppe99 ; # darf noch nicht vorhanden sein! ls: Gruppe99: Datei oder Verzeichnis nicht gefunden > mkdir Gruppe99 ; # X: Nummer von oben Jetzt können wir das Repository anlegen: > export CVSROOT=:local:~/PUB/Stud/Stud/sysop/Gruppe99 > cvs init Damit ist der Garten geschaffen. Was da ab ging: eigentlich noch gar nicht so arg viel, aber absolut notwendig. Ab sofort könnt ihr Module in euern Repository stellen. Und wie das geht seht ihr nächste Woche auf der nächsten Seite. 4 / 14 PAUL SCHEREMET

5 Das erste Modul importieren (import) Zunächst erzeugen wir uns ein Verzeichnis mit den ersten Dateien: > cd ; mkdir sysop ; cd sysop ; mkdir src > cd src ; mkdir server ; cd server > touch server.c ; touch server.h Jetzt setzen wir sie als erstes Modul in unser Repository: > export CVSROOT=:local:~/PUB/StudStud/Sysop-Gruppe1 > cvs import -m "Initial import" sysop/server gruppe99 start N sysop/server/server.c N sysop/server/server.h No conflicts created by this import Was da ab ging: -m "Initial import": Kommentar, angeben, sonst kommt ein Texteditor. sysop/server: die Dateien landen in $CVSROOT/sysop/server/... gruppe99: Angabe zum Ersteller (Vendor) start: Name der Veröffentlichung (Release) No conflicts created by this import: WICHTIG, sollte hier etwas anderes stehen, seid ihr in diesem Verzeichnis garantiert nicht alleine. HINWEIS: Module in CVS sind nicht das selbe wie in C! (es können beliebige Dateien in einem gemeinsamen Verzeichnis oder Unterverzeichnissen sein) Schauen, obs getan hat: Dazu checken wir das Modul aus (siehe nächste Seite)... 5 / 14 PAUL SCHEREMET

6 Module auschecken (checkout / co) Modul vom Repository lesen und in ein Verzeichnis ablegen: > cd../.. ; mv sysop/ sysop-old/ > cvs checkout sysop/server cvs checkout: Updating sysop/server U sysop/server/server.c U sysop/server/server.h > ls -lr./sysop: insgesamt 8 drwxr-xr-x 2... stud :49 CVS drwxr-xr-x 3... stud :49 server./sysop/cvs: insgesamt 12 [...] -rw-r--r stud :49 Repository -rw-r--r stud :49 Root./sysop/server: insgesamt 40 drwxr-xr-x 2... stud :49 CVS -rw-r--r stud :37 server.c -rw-r--r stud :37 server.h./sysop/server/cvs: insgesamt 12 [...] -rw-r--r stud :49 Root Wenn alles gut ging: rm -R sysop-old/ Was da ab ging: - Original Verzeichnis umbenannt - Modul ausgecheckt - Ergebnis betrachtet - Wenn alles gut ging das Original löschen 6 / 14 PAUL SCHEREMET

7 Module einchecken (commit) Quellcode abändern: Bearbeite oder ersetze eine Datei, z.b. server.c > cd sysop/server/ ; nano server.c Änderungen einchecken: > cvs commit -m "Code-cosmetics" server.c /home/stud/[...]/stud/stud/sysop/gruppe99/sysop/server/server.c,v <-- server.c new revision: 1.2; previous revision: 1.1 WICHTIG: -m "Kommentar" angeben, sonst kommt wieder der Editor :-( Was da ab ging: - Die Datei wurde verändert - CVS erhielt die neue Version und stellte keine Konflikte fest Die Datei hat eine neue Revision (hier: 1.2) die der nächste User auschecken wird 7 / 14 PAUL SCHEREMET

8 Dateien zu einem Modul hinzufügen (add & commit) Datei anlegen und hinzufügen: > cd sysop/server/ > touch server_signal_handling.c > cvs add server_signal_handling.c cvs add: scheduling file `server_signal_handling.c' for addition cvs add: use `cvs commit' to add this file permanently > cvs commit -m "add signal support" cvs commit: Examining. [...]/PUB/Stud/Stud/[...]/server_signal_handling.c,v <-- server_signal_handling.c initial revision: 1.1 Was da ab ging: - touch legt eine neue Datei an - CVS erhielt die Benachrichtigung über cvs add - cvs commit teilt CVS den Inhalt der Datei mit. - Die Datei hat die Revision m Kommentar": notwendig, weil sonst Editor aufgeht 8 / 14 PAUL SCHEREMET

9 Datei aus einem Modul entfernen(remove & commit) Datei entfernen: > cd sysop/server/ > rm server_signal_handling.c > cvs remove server_signal_handling.c cvs remove: scheduling `server_signal_handling.c' for removal cvs remove: use `cvs commit' to remove this file permanently > cvs commit -m "remove signal support" cvs commit: Examining. [...]/PUB/Stud/Stud/[...]/server_signal_handling.c,v <-- server_signal_handling.c new revision: delete; previous revision: 1.1 Was da ab ging: - zuerst die Datei löschen, sonst schlägt cvs remove fehl - CVS erhält die Benachrichtigung über cvs remove - cvs commit löscht die Datei schließlich - Die Datei bekommt die Revision delete - -m Kommentar": notwendig, weil sonst Editor aufgeht 9 / 14 PAUL SCHEREMET

10 Änderungen zum Repository anzeigen Datei entfernen: > cd sysop/server/ > vi server.c > cvs diff server.c Index: server.c =================================================================== RCS file: /home/stud/[...]/pub/stud/stud/sysop/gruppe99/sysop/server/server.c,v retrieving revision 1.3 diff -r1.3 server.c 4c4 < int delay = 0, status;; --- > int delay = 0, status; Was da ab ging: - zuerst die Datei bearbeiten - mit Hilfe von cvs diff die Änderungen abfragen - es wurden keine Veränderungen am Repository, sondern nur an der lokalen Kopie durchgeführt 10 / 14 PAUL SCHEREMET

11 Konflikte beim Einchecken Zwei unterschiedliche Stände erzeugen: ~$ mkdir test test1 ~$ cd ~/test1 ~/test1$ cvs co sysop/server [... Ausgabe von cvs co...] ~/test1$ cd sysop/server/ ~/test1/sysop/server$ nano server.c ~/test1/sysop/server$ cvs commit -m "Kommentar hier" server.c /home/stud/[...]/stud/stud/sysop/gruppe99/sysop/server/server.c,v <-- server.c new revision: 1.4; previous revision: 1.3 ~/test1/sysop/server$ cd ~/test ~/test$ cvs co sysop/server [... Ausgabe von cvs co...] ~/test$ cd sysop/server/ ~/test/sysop/server$ nano server.c ~/test/sysop/server$ cvs commit -m "Kommentar dort" server.c cvs commit: Up-to-date check failed for `server.c' cvs [commit aborted]: correct above errors first! Solche Konflikte entstehen dadurch, dass mindestens zwei Zustände die selbe Zeile verändern. Konflikte lösen Derjenige, der mit dem Konflikt konfrontiert wird, ist nun gefordert, seinen Quellcodeteil so weit abzuändern, dass das Mergen erfolgreich ist. Zur Not könnt ihr auch die fragliche Datei zwischenspeichern, zur aktuellen serverseitigen Version wechseln (siehe unten) und dann Zeile für Zeile anpassen. 11 / 14 PAUL SCHEREMET

12 Gewisse Dateien nicht versionieren (.cvsignore) Einige Dateien wollt ihr vielleicht nicht ins CVS mit aufnehmen, aber im selben Verzeichnis speichern, z.b. eine speziell für euren Computer geänderte Konfigurationsdatei. Diese Datei würde bei einem cvs update überschrieben werden. Damit das nicht passiert, kennt CVS eine Dateiliste, welche Dateien übersprungen werden sollen. Diese Liste besteht bereits auf den folgenden Mustern: RCS SCCS CVS CVS.adm RCSLOG cvslog.* tags TAGS.make.state.nse_depinfo *~ #*.#*,* _$* *$ *.old *.bak *.BAK *.orig *.rej.del-* *.a *.olb *.o *.obj *.so *.exe *.Z *.elc *.ln core Mit folgenden Möglichkeiten könnt ihr noch mehr definieren: $CVSROOT/CVSROOT/cvsignore.cvsignore in eurem Heimatverzeichnis (~/).cvsignore in einem Verzeichnis eures Projektes Umgebungsvariable $CVSIGNORE -I als Kommandozeilenparameter zu cvs hierbei ist noch zu beachten: wenn ihr ein! einbaut, löscht das eure Liste bis dorthin.cvsignore-einträge in einem Verzeichnis eures Projektes sind auch an dieses Verzeichnis gebunden 12 / 14 PAUL SCHEREMET

13 In der History zurück gehen > cd sysop/server/ > cvs update -j 1.2 -j 1.1 server.c RCS file: /home/stud/.../pub/stud/stud/sysop/gruppe99/sysop/server/server.c,v retrieving revision 1.2 retrieving revision 1.1 Merging differences between 1.2 and 1.1 into server.c cvs commit -m "back to Revision 1.1" server.c [...]/PUB/Stud/Stud/[...]/server.c,v <-- server.c new revision: 1.3; previous revision: 1.2 Wenn Ihr so etwas tut, denk daran, dass ihr stehts die Versionen der einzelnen Dateien beachten müsst, weil ein Verzeichnis Dateien mit unterschiedlichen Versionen beinhalten kann. dass ihr die Änderungen im Anschluss wieder committen müsst -m angeben, falls ihr keinen Editor wollt 13 / 14 PAUL SCHEREMET

14 Quellenangaben Informationen: Bilder: / 14 PAUL SCHEREMET