# Monotone und Arch « 02 « 2005 « Ausgaben « Heft & Abo « Linux-Magazin Online
Open Source im professionellen Einsatz
Author: Linux-Magazin Online
Keywords: Backup, Dateisysteme, Debian, Distributionen, Firewall, FTP, Gentoo, Migration, Python, SQLite, Suse, TCP, C++, Administration, SVN, Subversion, Speicher, SFTP, SQL, E-Mail, BSD, Development, HTTP

# Monotone und Arch

## Verteilung steuern

von Nico Schottelius
Erschienen im Linux-Magazin 2005/02

Open-Source-Programme entstehen meist örtlich und zeitlich versetzt. Im Gegensatz zu CVS und Subversion, die einen zentralen Server voraussetzen, versuchen sich die beiden Systeme Monotone und Arch mit einem dezentralen Ansatz, der bestehende Probleme zu lösen verspricht.

Versionskontrolle unter Linux bedeutet für die meisten Programmierer CVS. Dass dieses System auch einige Schwächen hat, ist allgemein bekannt. So kennt CVS weder einfaches Umbenennen noch Atomic Commits (siehe Kasten "Begriffe"). Es gibt verschiedene Alternativen, die diese Probleme lösen wollen, siehe[1].

Versionskontrollsysteme (Version Control Systems, kurz VCS, oder Source Control Management, kurz SCM) lassen sich anhand der Art, wie sie ihre Daten speichern und verwalten, in zwei Grundkategorien einteilen:

- Zentrale Datenhaltung und Administration
- Dezentrale, verteilte Speicherung und Organisation

Abbildung 1 zeigt den Unterschied zwischen den beiden Ansätzen. Das zentrale Modell dient vor allem dazu, den Wildwuchs an unterschiedlichen Programmvarianten zu verhindern. Jede bleibende Änderung findet ihren Niederschlag im Repository. Bevor Programmierer ihre Modifikationen in das Repository überführen, müssen sie sich erst die aktuelle Version herunterladen und entstandene Konflikte lösen. Der zentrale Server vergibt Versionsnummern und macht damit eine fortlaufende Nummerierung möglich (1.1 wird zu 1.2). Subversion[2] gehört zur ersten Art und war Thema im Linux-Magazin 06/03. Im Folgenden geht es um zwei freie Programme der dezentralen Variante: Gnu Arch[3] und Monotone[4].

#### Verteiltes gegen zentrales Entwickeln

Beim zentralen VCS ist der Server ein Single Point of Failure: Fällt er aus, kann kein Entwickler Daten aktualisieren oder verändern. Mit anderen unter VCS-Kontrolle Code austauschen ist dann nicht möglich. Wer ohne Zugriff aufs Dateisystem einen CVS-Server repliziert, verliert meist alle Änderungsinformationen. Die bleiben nur beim direkten Kopieren auf Dateisystemebene erhalten.

Die dezentralen oder auch verteilten Versionsverwaltungssysteme (Distributed Version Control Systems, kurz DVCS) erlauben mehrere (fast) identische Server. Jeder von ihnen führt sämtliche Informationen über Änderungen am Programmcode.

Jede Datei muss zu allen Zeiten eine eindeutige Versionsnummer besitzen. Ohne eine zentrale Vergabe der Nummern gibt es dafür zwei Ansätze: entweder über so genannte Hashes (zum Beispiel SHA1 oder MD5) oder mit Hilfe einer eindeutigen Namenskonvention.

In verteilten Versionsverwaltungssystemen tauschen die Benutzer ihre Daten direkt miteinander aus. Wenn die Arbeit untereinander abgeschlossen ist, transferiert ein Entwickler das gesammelte Ergebnis ins Hauptverzeichnis. Arbeitet ein anderer in der Zwischenzeit an einer älteren Version, müssen die Teile eventuell von Hand zusammengeführt werden. Dieser Fall ist jedoch äußerst selten, denn die meisten Systeme kennen dafür komplexe Algorithmen. Ein Beispiel ist das dreifache Zusammenfügen (Three Way Merge) in Monotone, das die meisten Konflikte selber löst.

#### Kandidat Nummer eins: Gnu Arch

Das Hauptprogramm von Gnu Arch[2] heißt »tla« (Tom Lord\'s Arch). Um Arch selbst zu kompilieren, ist das Quelltextpaket von[5] nötig, das nur von wenigen anderen Paketen abhängt[6]. Nach dem Entpacken des Quelltextpakets mit »tar xfz tla-Version.tar.gz« übersetzen die Standardschritte »./configure && make && make install« die Software. Per Default installiert das Skript das Programm nicht wie sonst üblich nach »/usr/ local«, sondern in ein Unterverzeichnis des Übersetzungsverzeichnisses. Abhilfe schafft »./configure --prefix= /Zielpfad«. So setzt man das Präfix gleich »/usr/packages/tla-Version«, um das Paket einfach entfernen zu können: »rm -rf /usr/ packages/tla-Version«.

| Abbildung 1: Zentrale und dezentrale Sourcecode-Kontrolle.

In diesem Fall ist es nötig, den Suchpfad mit »export PATH=:/usr/packages/tla-Version« anzupassen oder das »link_script« von[7] unter Angabe des Präfix einzusetzen. Einige aktuelle Distributionen bringen Arch mit, zum Beispiel Debian Sid (»apt-get install tla«), Gentoo oder Suse 9.1 (über Yast).

Hinter dem Kommando »tla« folgt ein Befehl, der angibt, was das Programm machen soll - ähnlich wie bei CVS. Alle verfügbaren Befehle zeigt »tla help«, eine Übersicht der weiteren Parameter und eine kurze Erklärung gibt »tla Kommando -H« .

Bei Arbeitsbeginn teilt der Entwickler dem Arch-System seine Identität mit, zum Beispiel »tla my-id "Nico Schottelius <my-tla@mx0.info>"«. Solche Parameter speichert das Programm in der Datei »~/.arch-params«. In der sollte auch suchen, wer »tla«-Fehlermeldungen erhält.

Begriffe

- Ein Versionskontrollsystem (Version Control System, VCS) stellt
  die Infrastruktur dafür bereit, dass mehrere Programmierer an
  unterschiedlichen Orten an demselben Projekt arbeiten
  können.
- Atomic Commits bezeichnen einen Zugriff auf ein VCS, der in
  einem konsistenten Status endet. Nach einem Verbindungsabbruch sind
  also entweder alle oder keine Änderungen wirksam geworden.
  Dies wird auch als Transaktion bezeichnet.
- Branches unterteilen die Daten in Zweige (zum Beispiel Branch
  »GUI« und »Console«).
- Tags sind Bezeichnungen der Daten im VCS zu einem bestimmten
  Zeitpunkt (Beispiel: »Sommerversion 2004«).

#### Eigenes Archiv

Als Nächstes braucht Arch ein Archivverzeichnis, in dem es die verwalteten Daten ablegt. Dazu dient folgendes Kommando:

    $ tla make-archive my-tla@mx0.info--<$>U
      2004-gpm ~/lm/tla/my-archive

Das Default-Archiv setzt der Tla-Befehl »my-default-archive«:

    $ tla my-default-archive my-tla@mx0.
      info--2004-gpm

Wer vergessen hat, »my-default-archive« zu setzen, erhält die Fehlermeldung »arch: no default archive set«. Alle vorhandenen Archive zeigt Tla mit dem Kommando »archives«:

    $ tla archives
    my-tla@mx0.info--2004-gpm
        /home/user/nico/lm/tla/gpm

Den vollständigen Pfad des Archivs zeigt folgender Befehl an:

    $ tla whereis-archive my-tla@mx0.
      info--2004-gpm
    /home/user/nico/lm/tla/gpm

Ein Tla-konformer Archivname setzt sich wie folgt zusammen: E-Mail-Adresse--Archivname--Suffix. Das kann zum Beispiel »my-tla@mx0.info--2004 --gpm« sein. Die E-Mail-Adresse identifiziert jenen Nutzer, der das Archiv verwaltet. Programmautor Tom Lord rät zur Benennung der Archive nach Jahreszahlen, im Beispiel »2004«, um zu große Archive zu vermeiden. Das Suffix verwendet man für die eigentliche Projektbezeichnung, hier »gpm«.

Im angelegten Archiv finden die einzelnen Projekte ihren Platz. Den zu reservieren ist Aufgabe des Kommandos »archive -setup«, es erhält als Parameter den Projektnamen in der Form: Projektname--Branch--Version. Verletzt man diese Namenskonvention, lässt zum Beispiel ein »-« weg, beschwert sich Arch:

    $ tla archive-setup gpm--main-1.20.1
    archive-setup: invalid package name
      gpm--main-1.20.1

Mit den richtigen Argumenten gibt Arch entsprechende Erfolgsmeldungen aus:

    $ tla archive-setup gpm--main--1.20.1
    * creating category my-tla@mx0.info--2004
      -gpm/gpm
    * creating branch my-tla@mx0.info--2004
      -gpm/gpm--main
    * creating version my-tla@mx0.info--2004
      -gpm/gpm--main--1.20.1

Das Archiv enthält nun ein Verzeichnis »gpm« für das neue Projekt:

    $ ls ~/lm/tla/my-archive
    =meta-info  gpm

Projekte unterteilen sich weiter in so genannte Branches, zum Beispiel »gpm --stable« und »gpm--Development«. Die folgende Versionsnummer lässt eine weitere Unterteilung zu, beispielsweise Version 1.20.1. Das Ganze ergibt dann den Archivnamen »gpm--stable--1.20.1«. Ist das Archiv angelegt, können die Quellen selbst dorthin wandern, im Beispiel jene des Gpm-Pakets[8].

#### Alte Sourcen initialisieren

Zuerst ist es erforderlich, die Sourcen in ihrem Verzeichnis (im folgenden Beispiel »~/lm/gpm«) mit »tla init-tree« zu initialisieren. Damit wird das Quellenverzeichnis zu einem Projektverzeichnis in Archs Sinn:

    $ cd ~/lm/gpm
    $ tla init-tree gpm--main--1.20.1

Nach diesem Kommando enthält das Verzeichnis »~/lm/gpm« ein Verzeichnis »{arch}« (inklusive der geschweiften Klammern). Die Arch-Befehle »tree-root« und »tree-version« verifizieren die bisherigen Eingaben:

    $ tla tree-root
    /home/user/nico/lm/gpm

    $ tla tree-version
    my-tla@mx0.info--2004-gpm/gpm--main--<$>U
    1.20.1

Die Initialisierung bewirkt nur Veränderungen im Unterverzeichnis »{arch}«, sie registriert das Projekt nicht im Archiv. Der Befehl »tla inventory --names --source« zeigt, welche Dateien Arch als Quellcode anerkennt. Es ignoriert zum Beispiel Dateinamen, die mit einer Tilde »~« enden, da es sich hierbei normalerweise um Backups handelt (für deren Anzeige sorgt »tla inventory --names --backups«). Die Eingabe »tla inventory --source« zeigt die Dateien an, die Arch ins Archiv aufgenommen hat. Da es bisher noch keine Dateien enthält, gibt der Befehl auch nichts aus.

Vorteile verteilter Kontrollsysteme

Entwickler arbeiten in diesem Modell miteinander, ohne auf den zentralen Server angewiesen zu sein. So können sie Quelltext untereinander austauschen und testen. Das hat mehrere Vorteile:

- Der Quelltext wird an verschiedenen Stellen getestet, bevor er
  in das Hauptlager gelangt.
- Entwickler können auch bei Ausfall des zentralen Servers
  miteinander arbeiten.
- Der Maintainer des Projekts wird von manuellen
  Quelltext-Aktualisierungen entlastet.

Ein Nachteil ist jedoch, dass durch die Übertragung aller Änderungen der Kommunikationsaufwand steigt.

#### Dateien ins Archiv übernehmen

Die Kombination »tla add Dateien« fügt endlich die Sourcefiles zum Archiv hinzu, mit einer Wildcard etwa alle im aktuellen Verzeichnis: »tla add *«. Der Befehl legt im Projektverzeichnis ein Unterverzeichnis ».arch-ids« an, in dem er die Dateien zum Hinzufügen vormerkt. Mit der Option »--source« zeigt der Arch-Befehl »inventory« die aufgenommenen Dateien, die Sourcecode enthalten: »tla inventory --source«. Andere im Archiv enthaltene Dateien listet Tla mit folgenden Parametern: »tla inventory --source --both«. Alle - auch nicht aufgenommene - Sourcen zeigt dagegen folgendes Arch-Idiom: »tla inventory --names --source«.

Entsprechend löscht »tla delete Datei(en)« im Archiv enthaltene Sourcefiles. Sind alle Dateien hinzugefügt, fehlt noch ein Logeintrag, der diese Aktion für die Nachwelt dokumentiert. Bei dieser Aufgabe hilft »tla make-log« und legt eine Datei an, in die der Entwickler mit einem Texteditor diesen Eintrag schreibt. In der Shell geht das auch in einem Schritt: »vi `tla make-log`«. Zum Abschluss überträgt »tla import« die Dateien in das Archiv:

    $ tla import
    * imported my-tla@mx0.info--2004-gpm/
    gpm--main--1.20.1

Die hier angezeigten Dateien erkennt Arch als Sourcecode, obwohl sie niemand mit »tla add« hinzugefügt hat. Deshalb nimmt »tla make-log« sie nicht in das Logfile auf, sondern zeigt sie nur zur Information an.

#### Archivstatus anzeigen

Die Kombination »tla revisions --summary --creator --date« liefert Informationen über Revisionen des Projekts. Will ein Entwickler Dateien zu einer neuen Revision hinzufügen, geht er die Schritte »add«, »make-log« und anschließend »commit« durch. Aus der ersten Revision »base-0« wird nach dem Commit »patch-1«. Eine Übersicht über die Revisionen gibt »tla revisions« aus.

Mit dem Parameter »--summary« zeigt Tla zusätzlich die Logeinträge. Beim Verschieben von Dateien hilft »tla move Quelle Ziel«. Das File auf dem Dateisystem muss der Entwickler jedoch selbst verschieben. Warum das so ist, erklärt der Wiki-Eintrag[9].

Gnu Arch überträgt seine Archive via FTP, SFTP, WebDAV oder HTTP. Im Folgenden soll sich das Archiv beispielsweise unter »http://linux.schottelius.org/archives/my-tla@mx0.info--2004-gpm« befinden.

| Abbildung 2: Für Arch gibt es das Webfrontend Archview, mit dem das Browsen der Archivinhalte möglich ist.

#### Zusammenarbeit im Netz

Andere Entwickler müssen dieses Archiv zunächst noch beim eigenen Arch registrieren:

    tla register-archive U my-tla@mx0.info--2004-gpm U http://linux.schottelius.org/archives/U my-tla@mx0.info--2004-gpm

Anschließend können sie es mit »tla get my-tla@mx0.info--2004-gpm Zielverzeichnis« herunterladen. Es besteht auch die Möglichkeit, eine ältere Version zu holen. Dazu ist zusätzlich noch die Revision anzugeben: »tla get my-tla@mx0.info--2004-gpm--base-0 Zielverzeichnis«.

#### Migration von CVS

Arch selbst bietet kein Kommando dafür, ein CVS-Repository umzuwandeln. Es gibt jedoch ein Tool namens Cscvs[10], das dabei hilft. Laut Homepage gibt es aber noch einige Probleme beim Import, sodass der Einsatz in einem Produktivsystem nicht unbedingt zu empfehlen ist. Für mehr Informationen zu Arch sei auf die Homepage[2] verwiesen, auf der sich eine sehr gute (englische) Anleitung[11] findet. Eine Hilfe speziell für CVS-Benutzer gibt[12]. Die Mailingliste ist meist recht hilfreich, jedoch wenig empfänglich für Kritik. Tla besitzt viele, teilweise kryptische Kommandos, von denen einige sich in ihrer Funktion überschneiden.

Arch gibt es nicht für Windows, jedoch soll Py Arch[13] einen Tla-Wrapper mit derselben Funktionalität bereitstellen. Beim Austausch mit anderen Betriebssystemen kann es zu Problemen mit der Dateinamensbegrenzung kommen, da Tla grundsätzlich alle Zeichen erlaubt, die das Dateisystem zulässt.

Die eigenartige Versionsbezeichnung von Archiven ist bedingt durch die dezentrale Architektur. Nach Meinung der Programmautoren ist das jedoch vor allem eine Frage der Gewöhnung. Wer sich nicht daran gewöhnen kann und Argumentationshilfe gegen Arch braucht, findet sie unter[14].

#### Kandidat Nummer zwei: Monotone

Entwickler Graydon Hoare ist der geistige Vater des ebenfalls dezentralen Versionskontrollsystems Monotone. Dessen Architektur beschrieb er auf der Entwickler-Mailingliste so: Verteilt, dezentral, ohne Server. Es gibt keinen einzelnen Punkt für Ausfall, Vertrauen oder Kommunikation und keinen Unterschied zwischen Clients und Servern.

Monotone ist bei allen großen Distribution nicht von Haus aus enthalten. Die Homepage[4] führt aber Pakete für Fedora und Debian, ja sogar einen Win32-Port. Um Monotone aus dem Quelltext zu kompilieren, braucht man einige Entwicklungspakete von Boost (siehe[15] und den Artikel in diesem Heft).

Unter Debian: »libboost-date-time-dev«, »libboost-filesystem-dev«, »libboost-regex- dev«, »libboost-test-dev«, »libboost -dev« und »libpopt-dev«. Eine Übersicht über die Abhängigkeiten gibt[16]. Ist das Paket entpackt, folgen »./configure && make« und »make install« als Administrator. Bewährt hat sich dafür folgende Kommandozeile:

    ./configure --prefix=/usr/packages/monotone -0.13 && make && su -c "make install && U link-packages /usr/packages/monotone-0.13"

Das Skript »link-packages« findet sich wiederum unter[7].

Erster Schritt ist das Anlegen der SQLite-Datenbank, die Monotone voraussetzt:

    monotone --db=Name.db db init

Anschließend ist es wie bei Arch üblich, sich dem VCS vorzustellen. Die Identität des Benutzers stellt Monotone mit einem Public-Key-Verfahren sicher. Das Schlüsselpaar (privat und öffentlich) erzeugt man über den Befehl »monotone --db= Name.db genkey my-tla@mx0 .info«. Alle Schlüssel zeigt das Kommando »monotone --db= Name.db list keys«. Wer Dateien hinzufügen will, wechselt ins Projektverzeichnis und führt das Monotone-Kommando »add« aus, beispielsweise:

    monotone --db=../Name.db --branch=org. schottelius.gpm add *

Auch Monotone ignoriert einige Dateitypen, insbesondere CVS-Verzeichnisse. Der aktuell bearbeitete Zweig (Branch) sollte dem umgedrehten Domainnamen des Projekts entsprechen, im Beispiel »org.schottelius.gpm«.

Unterprojekte werden einfach angehängt. So könnte der BSD-Port von »gpm« den Namen »org.schottelius.gpm .bsd-port« erhalten. Der Befehl verursacht keine Änderung an der Monotone-Datenbank, legt aber ein Verzeichnis »MT« an. In diesem Verzeichnis gibt es zwei neue Dateien: »work« speichert Änderungen, die noch nicht in die Datenbank geschrieben wurden. In »options« stehen Parameter wie der Branch oder der Speicherort der Datenbank.

Die Dateien der Datenbank hinzufügen ist Aufgabe des Monotone-Befehls »commit« - jetzt ohne »--db=...«, da die Datenbank bereits in »options« vermerkt ist. Der Befehl startet den Editor, den die Umgebungsvariable »EDITOR« enthält, um einen Kommentar einzutragen. Danach fordert Monotone zur Eingabe des Passworts auf, um die Daten mit dem privaten Schlüssel zu signieren und in die Datenbank zu übertragen.

Dabei gibt es eine Zeile ähnlich »monotone: committing a334960b9a773c4b5b5 21f8bffb9d3bb31f5e3e0« aus. Diese kryptische Mitteilung enthält den SHA1-Hash der aktuellen Daten. Monotone verwendet solche Hashes als Versionsbezeichnung. Der Befehl »cat MT/manifest« gibt die Hashes aller Dateien aus.

Monotone hat wie Arch eine spezielle Eigenart bei der Bezeichnung von Versionen: Die angesprochenen SHA1-Hashes identifizieren zwar eine Datei eindeutig, sie können jedoch nicht ansteigend verlaufen. Um nicht jedes Mal den kompletten Hash tippen zu müssen, enthält Monotone einen Algorithmus zur Vervollständigung. Eine Alternative zum obigen Beispiel verwendet deshalb nur den Hash-Anfang »a334«: »monotone --db= Name.db cat manifest a334«.

#### Für die Öffentlichkeit

Monotone ist Client- und Serverprogramm in einem. Vor dem Start des Servers extrahiert man den Public-Key aus der Datenbank: »monotone --db= Name.db pubkey my-tla@mx0.info > server-key.pub«. Die Option »serve« startet Monotone im Servermodus:

    monotone --db=Name.db serve
     linux.schottelius.org org.schottelius.gpm
     2>&1 | tee -a monotone.log

Dieses Kommando startet den Monotone-Server auf »linux.schottelius.org« mit der so genannten Kollektion (einer Sammlung von Branches) »org.schottelius.gpm«. Der Teil hinter »2>&1« schreibt die Ausgabe in die Logdatei »monotone.log«. Wer eine Firewall betreibt, muss für Monotone den Port 5253 (TCP) freigeben.

Will ein Entwickler die Kollektion herunterladen, holt er sich zuerst den Public-Key und gibt ihn mit »monotone --db= Neu.db read < server-key.pub« ein. Dann lädt er die Daten mit dem Befehl »monotone --db= Neu.db pull linux .schottelius.org org.schottelius.gpm« in seine neue Datenbank. Anschließend extrahiert er die aktuelle Version mit »monotone --db=Neu.db --branch=org.schottelius.gpm co gpm« in das Verzeichnis »gpm«. Bei Änderungen an den Dateien schreibt er diese mit »commit« in die lokale Datenbank und teilt sie schließlich noch dem Monotone-Server mit:

    monotone --db=Neu.db --branch=org.schottelius.gpm push linux.schottelius.org org.schottelius.gpm

Monotone kennt auch die Möglichkeit, ein Push und ein Pull gleichzeitig durchzuführen, also in beiden Richtungen auf einmal zu synchronisieren. Dazu dient die Monotone-Option »sync«.

| Abbildung 3: Monotone erlaubt es, von einer Ursprungsversion Abzweigungen zu bilden, die Entwickler getrennt bearbeiten. Danach fügen sie sie wieder zu einer gemeinsamen Version zusammen.

#### Zusammenarbeit mit Köpfchen

Wenn zwei Entwickler an einer Version arbeiten, produzieren sie zwei neue Abzweigungen, auch Heads genannt, siehe Abbildung 3. Normalerweise lassen sich diese Heads mit »monotone merge« zusammenfügen. Klappt das nicht, hilft nur Handarbeit. Um eine alte Version wieder hervorzuholen, ist zusätzlich die ID erforderlich:

    monotone co f22d21778173b3f5df04cb9524e722cdabcd7cd4 ~/Alte-Version

Für das Übernehmen einer CVS-Datenbank (Repository) in Monotones Datenbank bringt das Paket den Befehl »cvs_import« mit: »monotone --db= Name.db --branch= org.schottelius.cvs-import cvs_import CVS-Repository«.

#### Gesamteindruck und Eigenarten

Ein großer Vorteil von Monotone ist die einfache Handhabung. Auch die Mailingliste ist sehr hilfreich: Meist liefern die Teilnehmer innerhalb eines Tages Lösungen zu den Problemen. Ebenso schnell nehmen die Entwickler Änderungen an. Ein ausführliches Tutorial ist unter[17] zu finden.

Häufig wird in den Monotone-Foren die Frage gestellt: Kann man einen Public Key auch löschen, um Zugriffe zu verhindern? Die Antwort lautet: Nein, das wäre sinnlos! Dann wüsste man nicht mehr, von wem der Quelltext kommt. Um jemandem den Zugang zu entziehen, widerruft der Datenbankbesitzer daher einfach die Gültigkeit des Schlüssels.

Tabelle 1 vergleicht die wichtigsten Eigenschaften der Versionskontrollsysteme CVS, SVN, Arch und Monotone. Eine detaillierte Aufstellung gibt[1]. Monotone und Arch lassen sich jedoch nur bedingt mit CVS und SVN vergleichen, da der Ansatz (zentral vs. dezentral) grundverschieden ist.

Tabelle 1: Vergleich der Systeme
Merkmal | CVS | Subversion | Gnu Arch | Monotone
Bedienungskomfort | gut | gut | mäßig | gut
Changesets | nein | ja | ja | ja
Atomic Commits | nein | nein | ja | ja
Zentral/dezentral | zentral | zentral | dezentral | dezentral
Binärdiff | nein | Vdelta | nein | Xdelta

#### Noch unentschieden

Der Unix-Quasistandard CVS ist weit verbreitet, viele Zusatztools erleichtern die Arbeit mit diesem System. Fehlende Features wie Atomic Commit schränken die Nützlichkeit jedoch stark ein. Subversion als designierter Nachfolger des zentralen CVS behebt viele Fehler des älteren Systems und besitzt ebenfalls schon eine große Sammlung an praktischen Zusatztools.

Gerade im Bereich der Open-Source-Entwicklung ist die zentrale Architektur aber ein Nachteil. Gnu Arch nutzt die bereits vorhandene Linux-Infrastruktur und verfolgt damit das Unix-Prinzip, kleiner kombinierbarer Programme. Ansonsten stützt es sich zur Datenspeicherung nur auf den Funktionsumfang des Dateisystems. Leider ist Archs Handhabung sehr kompliziert.

Monotone vereint Server und Client in einem Programm und ist trotz C++-Code und eigener SQLite-Datenbank performant. Es funktioniert an einigen Stellen noch nicht hundertprozentig, scheint aber trotzdem das größere Potenzial zu besitzen. (ofr)

Infos

[1] VCS-Vergleich: [http://better-scm.berlios.de/comparison/comparison.html]

[2] Subversion: [http://subversion.tigris.org]

[3] Gnu-Arch-Homepage: [http://regexps.srparish.net/www/#Gnu-arch]

[4] Monotone-Homepage: [http://www.venge.net/monotone/]

[5] Arch-Quelltextarchiv: [ftp://ftp.gnu.org/gnu/gnu-arch]

[6] Arch-Abhängigkeiten: [http://regexps.srparish.net/www/arch-facts.html]

[7] »link-script«: [http://linux.schottelius.org/clinux/scripts/link-packages]

[8] Gpm: [http://linux.schottelius.org/gpm/]

[9] Dateien verschieben mit Arch: [http://regexps.srparish.net/www/tutorial/html/inventory-ids.html#Why_is_it_Like_This _--_Why_tla_move_Doesn\'t_Move_Files]

[10] CVS-Arch-Migration mit Cscvs: [http://wiki.gnuarch.org/moin.cgi/cscvs]

[11] Arch-Tutorial: [http://regexps.srparish.net/www/tutorial/html/arch.html]

[12] Arch-Befehle für CVS-Benutzer: [http://wiki.gnuarch.org/moin.cgi/Learning_20Arch_20commands_20for_20CVS_20users]

[13] Tla-Python: [http://ddaa.net/pyarch.html]

[14] Warum kein Arch?: [http://wiki.gnuarch.org/moin.cgi/Why_20not_20Arch]

[15] Boost: [http://www.boost.org]

[16] Monotone-Abhängigkeiten: [http://www.venge.net/monotone/INSTALL]

[17] Monotone-Tutorial [http://www.venge.net/monotone/docs/index.html]

[18] Blacksheep: [http://linux.schottelius.org/blacksheep/]

Der Autor
Nico Schottelius ist mit Linux 2.0 zur Open- Source-Gemeinde gestoßen. Er arbeitet an verschiedenen Linux-Projekten mit, unter anderem an Blacksheep [18]. Im Berufsleben hilft er Unternehmen dabei, zu Linux zu migrieren. Wenn er sich nicht gerade beim Rock\'n\'Roll-Tanzen entspannt, ist er unter [nico-linux-magazin@schottelius.org] zu erreichen.

Dieser Online-Artikel kann Links enthalten, die auf nicht mehr vorhandene Seiten verweisen. Wir ändern solche "broken links" nur in wenigen Ausnahmefällen. Der Online-Artikel soll möglichst unverändert der gedrucken Fassung entsprechen.
Impressum |Datenschutzerklärung | © 2009Linux New Media AG
Partner-Sites
Deutschland: [LinuxUser] [EasyLinux] [Linux-Community]
Europa: [EasyLinux Polen] [Linux Magazine Polen] [Linux Magazine Spanien]
International: [Linux Magazine International] [Linux Pro Magazine] [Linux Magazine Brasilien] [EasyLinux Brasilien]