Rheinwerk Computing :: Linux - 30 Softwareentwicklung

30.13 Versionsmanagement

Seit einigen Jahren werden sogenannte Versionsmanagement-Systeme in der Softwareentwicklung immer populärer. Da gibt es beispielsweise Visual SourceSafe von Microsoft oder Subversion für Unix, Windows und Linux. Diese Systeme kümmern sich primär darum, dass mehrere Entwickler ohne weitere Probleme an einer Software – und damit auch an den gleichen Quelldateien – arbeiten können. Die Dateien werden dabei auf einem System abgelegt, auf das alle Zugriff haben. Ein Entwickler kann von solch einem System die aktuellen Quelldateien (und damit auch die Veränderungen, die von anderen an den Dateien vorgenommen wurden) auf seinen Rechner übertragen und ist gleichzeitig in der Lage, seine eigenen Änderungen an dieses System zu übermitteln.

Wir werden uns in diesem Buch auf die zwei populärsten Versionsmanagement-Systeme für Linux und Unix konzentrieren: CVS und Subversion. Der Vollständigkeit halber sei erwähnt, dass es für beide Systeme auch Skripte (CVS) bzw. Apache-Module (Subversion) für den Zugriff via Webbrowser gibt.

30.13.1 CVS

CVS, das Concurrent Versions System, gibt es schon seit vielen Jahren. Es ist noch immer eines der meistgenutzten Versionsmanagement-Systeme. Viele große Projekte wie das OpenBSD-Projekt verwenden CVS. Wir selbst nutzen CVS ebenfalls seit einigen Jahren für die Arbeit an unseren Büchern und an einigen gemeinsamen Projekten.

Ein Projekt anlegen

Repository

Zunächst muss man ein Projektverzeichnis erschaffen, auf das alle Entwickler zugreifen können. Dazu genügt bereits ein SSH-Server. Auf diesem legt man unter dem gemeinsamen Benutzer, in diesem Fall »swendzel«, ein Verzeichnis für das jeweilige Projekt an. Es empfiehlt sich dabei, ein globales CVS-Verzeichnis (Repository) einzurichten, in das man alle Projekte eingliedern kann. So erspart man sich später die Arbeit, die Umgebungsvariable CVSROOT für jedes Projekt zu ändern.

Listing 30.71 Das Projekt »projekt« anlegen

$ cd
$ mkdir .cvs
$ mkdir .cvs/CVSROOT
$ mkdir .cvs/projekt

CVS-Projekte werden Module genannt. Module bezeichnen Verzeichnisse im CVS-Repository, in denen die Dateien eines Projekts enthalten sind.

Entwicklungsbeginn

Auf den jeweiligen Entwickler-Workstations setzt man nun die Shellvariable CVSROOT auf den CVS-Benutzer des Projektsystems und das entsprechende Verzeichnis in der Form Benutzer@Host:/Verzeichnis. Zudem sollte man ssh verwenden, was durch CVS_RSH angegeben wird.

Listing 30.72 CVSROOT setzen

$ export CVSROOT='swendzel@192.168.0.2:/home/swendzel/.cvs'
$ export CVS_RSH="ssh"

Bevor die Entwicklung beginnen kann, muss jeder Entwickler noch den aktuellen Auszug des jeweiligen Moduls aus dem CVS-Repository laden. An dieser Stelle kommt zum ersten Mal das Tool cvs zum Einsatz. Man verwendet dessen Befehl checkout, der alle aktuellen Dateien überträgt und somit eine lokale Kopie des aktuellen Projektverzeichnisses anlegt.

Listing 30.73 Checkout von »projekt«

$ ls
$ cvs checkout projekt
cvs checkout: Updating projekt
$ ls
projekt

Dateien und Veränderungen

add und commit

Als Nächstes fügt man eine Datei zum Projekt hinzu, beispielsweise eine .c-Datei. Diese legt man zunächst lokal an und überträgt sie dann mit dem Befehl add ins Repository-Modul. Anschließend nutzt man den Befehl commit, um die lokalen Änderungen auf das CVS-System zu übertragen. Dieses Kommando verwendet man auch, wenn man etwas an einer bereits bestehenden Datei verändert hat und die Änderungen auf das CVS-System übertragen möchte. Hinter dem Parameter -m wird dabei ein Kommentar zu dieser Veränderung eingetragen.

Listing 30.74 Eine Quellcode-Datei erstellen und übertragen

$ cd projekt
$ cat << EOF >test.c
> #include <stdio.h>
>
> int main(int argc, char *argv[]) {
>    printf("Hello!\n");
>    return 0;
> }
> EOF
$ cvs add test.c
cvs add: scheduling file `test.c' for addition
cvs add: use `cvs commit' to add this file permanently
$ cvs commit -m 'Erste Version von test.c'
cvs commit: Examining .
RCS file: /home/swendzel/.cvs/projekt/test.c,v
done
Checking in test.c;
/home/swendzel/.cvs/projekt/test.c,v  <--  test.c
initial revision: 1.1
done

delete

Soll hingegen eine Datei gelöscht werden, wird der Befehl delete verwendet. Damit keine unbeabsichtigten Löschvorgänge durchgeführt werden, erklärt sich CVS jedoch erst bereit, eine Datei zu löschen, wenn man diese auch lokal gelöscht hat. Auch hiernach müssen wieder mit commit die Änderungen an den CVS-Server geschickt werden.

Listing 30.75 delete

$ cvs delete test.c
cvs remove: file `test.c' still in working directory
cvs remove: 1 file exists; remove it first
$ rm test.c
$ cvs delete test.c
cvs remove: scheduling `test.c' for removal
cvs remove: use `cvs commit' to remove this file
            permanently
$ cvs commit -m ''
cvs commit: Examining .
Removing test.c;
/home/swendzel/.cvs/projekt/test.c,v  <--  test.c
new revision: delete; previous revision: 1.1
done

Nun arbeiten in der Regel mehrere Entwickler an einem Projekt. Damit diese ebenfalls Änderungen an den Quellcodes durchführen und eventuell neue Dateien einbringen können, sollte man sich diese Änderungen und neuen Dateien in regelmäßigen Abständen herunterladen. Dies wird mit dem Befehl up (auch update) erledigt. Man sollte dabei den Parameter -d übergeben. Dieser legt, falls notwendig, neue Verzeichnisse an.

Listing 30.76 cvs up -d

$ cvs up -d
cvs update: Updating .
P Makefile
$

log

Wichtig bei der Arbeit mit CVS ist auch, dass man sich über die Änderungen, die am Quellcode vorgenommen werden, auf dem Laufenden hält. Dafür nutzt man den Befehl log und übergibt ihm die Namen der Dateien, zu denen man die Änderungsinformationen wünscht. Dabei erscheinen übrigens die Strings, die Sie bei einem commit-Befehl hinter dem -m-Parameter übergeben.

Listing 30.77 cvs log-Makefile

$ cvs commit -m 'Suffixregel f. c.o.'
cvs commit: Examining .
Checking in Makefile;
/home/swendzel/.cvs/projekt/Makefile,v  <--  Makefile
new revision: 1.3; previous revision: 1.2
done
$ cvs log Makefile

RCS file: /home/swendzel/.cvs/projekt/Makefile,v
Working file: Makefile
head: 1.3
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 3;     selected revisions: 3
description:
----------------------------
revision 1.3
date: 2005/06/26 17:12:58;  author: swendzel;  state:
Exp;  lines: +2 –0
Suffixregel f. c.o.
----------------------------
revision 1.2
date: 2005/06/26 16:57:50;  author: swendzel;  state:
Exp;  lines: +1 –0
*** empty log message ***
----------------------------
revision 1.1
date: 2005/06/26 16:56:05;  author: swendzel;  state:


Exp;
*** empty log message ***
=====================================================

Falls Sie weitere Informationen zu CVS suchen, empfehlen wir Ihnen [Bud05A].

30.13.2 Subversion

Die Weiterentwicklung des Concurrent Versions System nennt sich Subversion. Sie bietet gegenüber CVS einige Vorteile und hat im Grunde nur einen einzigen Nachteil: Subversion benötigt mehr Speicherplatz. Dies liegt daran, dass es von jeder veränderten Datei eine Kopie sichert. Zudem nutzt Subversion ein anderes Versionsschema als CVS.

Die Vorteile bestehen nun darin, dass es zusätzliche Befehle gibt und dass Dateien und Verzeichnisse umbenannt werden können. Bei CVS musste man diese noch löschen und unter einem neuen Namen anlegen, um sie »umzubenennen«. Verbessert wurde auch die Handhabung von Binärdateien. Außerdem kann über ein Modul für den Webserver Apache 2.x auf das Repository zugegriffen werden. Für CVS gibt es allerdings CVSweb, das unter der BSD-Lizenz erhältlich ist und Ähnliches ermöglicht. [Fn. Falls Sie sich CVSweb einmal ansehen möchten, sollten Sie die Adresse www.openbsd.org/ cgi-bin/cvsweb/ besuchen.] Die Befehle stimmen mit denen von CVS ungefähr überein; daher im Folgenden nur einige Beispiele für die wichtigsten Befehle.

Eigene Veränderungen können via svn commit auf den Server übertragen werden.

Listing 30.78 svn commit

$ svn commit -m 'Buffer Overflow Fix in recv.c'

Um die aktuelle Version vom Repository auf den eigenen Rechner zu übertragen, wird – wie bei CVS – der Befehl up verwendet.

Listing 30.79 svn up

$ svn up
Revision 755.

Der Befehl log zeigt die letzten Commits des Repositorys an. Im Folgenden sehen Sie einen Auszug der letzten Veränderungen im Subversion-Repository der Hardened Linux Distribution.

Listing 30.80 svn log

$ svn log
--------------------------------------------------------------------
r755 | cdpxe | 2007-04-11 23:57:39 +0200 (Mi, 11 Apr 2007) | 1 line

remove unneded old config archives+sign files
--------------------------------------------------------------------
r754 | cdpxe | 2007-04-11 23:44:08 +0200 (Mi, 11 Apr 2007) | 1 line

aaa_hl pkg update for 1.6.6
--------------------------------------------------------------------
r753 | cdpxe | 2007-04-11 23:42:51 +0200 (Mi, 11 Apr 2007) | 1 line

current internal dev version is 1.6.6 from now on *har har*
--------------------------------------------------------------------
r752 | cdpxe | 2007-04-11 23:38:21 +0200 (Mi, 11 Apr 2007) | 1 line

update for 1.6.5 (upload after the release, not now)
--------------------------------------------------------------------
r751 | cdpxe | 2007-04-11 21:12:32 +0200 (Mi, 11 Apr 2007) | 1 line

remove slackware/l/gd because we already have the package in
universe/l/gd
--------------------------------------------------------------------
...
...

Das Umbenennen von Dateien und ganzen Verzeichnissen ist in Subversion auch kein Problem.

Listing 30.81 svn rename

$ svn rename pakete packages

Lokale Veränderungen lassen sich mit dem stat-Befehl anzeigen. Dieser Befehl ist äußerst sinnvoll, wenn man sehen möchte, was man alles modifiziert hat, und anschließend die Veränderungen in mehrere einzelne Commits aufteilen möchte.

Das Hinzufügen von Dateien zum Repository geschieht mit svn add und das Löschen mit svn remove, worauf jeweils ein svn commit folgen sollte. Lokale Änderungen können mit svn revert rückgängig gemacht werden und Metainformationen zum ausgecheckten Repository erhält man durch svn info.

Listing 30.82 svn info für das WendzelNNTPd-Repository

$ svn info
Pfad: .
URL: https://wendzelnntpd.svn.sourceforge.net/svnroot/
             wendzelnntpd
Basis des Projektarchivs: https://wendzelnntpd.svn.
             sourceforge.net/svnroot/wendzelnntpd
UUID des Projektarchivs:
             997a3042-3631-0410-9e25-ea9ec5d3c7cf
Revision: 524
Knotentyp: Verzeichnis
Plan: normal
Letzter Autor: cdpxe
Letzte geänderte Rev: 524
Letztes Änderungsdatum: 2011-03-01 23:01:44 +0100
(Di, 01. Mär 2011)

30.13.3 Git

Ein weiteres, recht neues und zudem verteiltes System zur Quellcodeverwaltung nennt sich Git. Es wurde ursprünglich dafür entwickelt, bei der Kernelentwicklung von Linux zum Einsatz zu kommen, ist mittlerweile aber weit verbreitet. Bei Git werden alle Repository-Informationen inklusive aller Versionsunterschiede auf jedem, in die Entwicklung involvierten, System hinterlegt und jedes System kann sowohl die Rolle eines Clients als auch eines Servers übernehmen. Wie schon für Subversion möchten wir eine Übersicht der wichtigsten Befehle für Git am Beispiel des Hosters github.org und des Projekts openccd geben:

Zunächst soll ein Repository geklont werden, damit es von github auf den lokalen Rechner übertragen werden. Die entsprechende URL lässt sich auf der jeweiligen github-Projektseite unter dem Punkt »Source« finden.

Listing 30.83 git clone

$ git clone https://cdpxe@github.com/OpenCCD/OpenCCD.git
Initialized empty Git repository in /tmp/OpenCCD/.git/
Password:
remote: Counting objects: 152, done.
remote: Compressing objects: 100 % (105/105), done.
remote: Total 152 (delta 72), reused 121 (delta 41)
Receiving objects: 100 % (152/152), 46.17 KiB, done.
Resolving deltas: 100 % (72/72), done.

Änderungen können ähnlich, wie bei den bereits bekannten Systemen CVS und Subversion durchgeführt werden, müssen aber nach einem commit noch mit git push auf den Server übertragen werden. Um Änderungen eines entfernten Repositories auf den eigenen Rechner zu übernehmen muss hingegen git pull ausgeführt werden. Das Hinzufügen von Dateien funktioniert analog mit git add, das löschen von Dateien mit git rm.

Im Folgenden soll beispielhaft eine Änderung an einem Makefile vorgenommen werden. Nach Eingabe von git commit -a öffnet sich ein Editor zur Eingabe eines Kommentars (dies erfüllt denselben Zweck wie svn commit -m 'Kommentar'). Lokale Änderungen können über git diff angezeigt werden.

Listing 30.84 Weitere git-Befehle

$ cd OpenCCD
$ vim Makefile
...
$ git commit -a
[master 3743af7] Add trainling newline
 Committer: Steffen Wendzel
     <swendzel@steffenmobile.(none)>
Your name and email address were configured
automatically based on your username and hostname.
Please check that they are accurate.
You can suppress this message by setting
them explicitly:

 git config --global user.name "Your Name"
 git config --global user.email you@example.com

If the identity used for this commit is wrong, you
can fix it with:

 git commit --amend
   --author='Your Name <you@example.com>'

 1 files changed, 2 insertions(+), 0 deletions(-)
$ git push
Password:
Counting objects: 5, done.
Delta compression using up to 2 threads.
Compressing objects: 100 % (3/3), done.
Writing objects: 100 % (3/3), 308 bytes, done.
Total 3 (delta 2), reused 0 (delta 0)
To https://cdpxe@github.com/OpenCCD/OpenCCD.git
   72c02e4..3743af7  master -> master
$ git pull
Password:
Already up-to-date.

Die Versions-History kann wie bei Subversion mit dem log-Befehl abgefragt und zur Erhöhung der Übersichtlichkeit dabei zusätzlich die Option --color hinzugefügt werden.

Listing 30.85 git log

$ git log
commit 3743af74ad2f855191e644bdcd7ecea2134f028d
Author: Steffen Wendzel <swendzel@steffenmobile.(none)>
Date:   Mon Jun 20 11:43:35 2011 +0200

    Add trainling newline

commit 72c02e4f10c11dd206d1f84a490f9e9429cb6241
Author: Steffen Wendzel <swendzel@swendzel-A880GU3.(none)>
Date:   Sun Jun 19 18:09:20 2011 +0200

    Add some develoment hints.

commit dc4692fc51649106356b361cfceeee1bc5f7e117
Author: Steffen Wendzel <swendzel@swendzel-A880GU3.(none)>
Date:   Sun Jun 19 18:05:06 2011 +0200

    Add explaining comments and implement the packet walktrough in
    modbar.c.

Ihre Meinung

Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de.