English ▾ Themen ▾ Neueste Version ▾ git-cvsserver zuletzt aktualisiert in 2.50.0

NAME

git-cvsserver - Ein CVS-Server-Emulator für Git

SYNOPSIS

SSH

export CVS_SERVER="git cvsserver"
cvs -d :ext:user@server/path/repo.git co <HEAD_name>

pserver (/etc/inetd.conf)

cvspserver stream tcp nowait nobody /usr/bin/git-cvsserver git-cvsserver pserver

Verwendung

git-cvsserver [<options>] [pserver|server] [<directory> …​]

BESCHREIBUNG

Diese Anwendung ist eine CVS-Emulationsschicht für Git.

Sie ist sehr funktionsfähig. Allerdings sind nicht alle Methoden implementiert, und für die implementierten Methoden sind nicht alle Schalter implementiert.

Tests wurden sowohl mit dem CLI CVS-Client als auch mit dem Eclipse CVS-Plugin durchgeführt. Die meisten Funktionen funktionieren mit beiden Clients gut.

OPTIONEN

Alle diese Optionen sind offensichtlich nur sinnvoll, wenn sie serverseitig durchgesetzt werden. Sie wurden implementiert, um den Optionen von git-daemon[1] so genau wie möglich zu ähneln.

--base-path <pfad>

Hängt pfad an die angeforderte CVSROOT an

--strict-paths

Erlaube kein rekursives Suchen in Unterverzeichnissen

--export-all

Prüfe nicht auf gitcvs.enabled in der Konfiguration. Du musst auch eine Liste erlaubter Verzeichnisse angeben (siehe unten), wenn du diese Option verwenden möchtest.

-V
--version

Versionsinformationen ausgeben und beenden

-h
-H
--help

Nutzungsinformationen ausgeben und beenden

<Verzeichnis>

Die verbleibenden Argumente liefern eine Liste von Verzeichnissen. Wenn keine Verzeichnisse angegeben werden, sind alle erlaubt. Repositories innerhalb dieser Verzeichnisse erfordern weiterhin die Konfigurationsoption gitcvs.enabled, es sei denn, --export-all wird angegeben.

EINSCHRÄNKUNGEN

CVS-Clients können keine Tags, Branches oder Git-Merges durchführen.

git-cvsserver ordnet Git-Branches CVS-Modulen zu. Dies unterscheidet sich stark von dem, was die meisten CVS-Benutzer erwarten würden, da CVS-Module normalerweise ein oder mehrere Verzeichnisse darstellen.

INSTALLATION

  1. Wenn du CVS-Zugriff über pserver anbieten möchtest, füge eine Zeile wie diese in /etc/inetd.conf ein:

       cvspserver stream tcp nowait nobody git-cvsserver pserver

    Hinweis: Einige inetd-Server erlauben dir, den Namen der ausführbaren Datei unabhängig vom Wert von argv[0] anzugeben (d.h. den Namen, den das Programm annimmt, mit dem es ausgeführt wurde). In diesem Fall sieht die richtige Zeile in /etc/inetd.conf so aus:

       cvspserver stream tcp nowait nobody /usr/bin/git-cvsserver git-cvsserver pserver

    Standardmäßig bietet pserver nur anonymen Zugriff. Zum Committen musst du pserver-Konten erstellen, füge einfach eine gitcvs.authdb-Einstellung in der Konfigurationsdatei der Repositories hinzu, zu denen der cvsserver Schreibzugriff erlauben soll, zum Beispiel:

       [gitcvs]
	authdb = /etc/cvsserver/passwd

    Das Format dieser Dateien ist Benutzername gefolgt vom verschlüsselten Passwort, zum Beispiel:

       myuser:sqkNi8zPf01HI
   myuser:$1$9K7FzU28$VfF6EoPYCJEYcVQwATgOP/
   myuser:$5$.NqmNH1vwfzGpV8B$znZIcumu1tNLATgV2l6e1/mY8RzhUDHMOaVOeL1cxV3

    Du kannst die htpasswd-Funktion, die mit Apache geliefert wird, verwenden, um diese Dateien zu erstellen, aber nur mit der Option -d (oder -B, wenn dein System sie unterstützt).

    Bevorzuge das systemspezifische Dienstprogramm zur Erstellung von Passwort-Hashes auf deiner Plattform (z. B. mkpasswd unter Linux, encrypt unter OpenBSD oder pwhash unter NetBSD) und füge es an der richtigen Stelle ein.

    Gib dann dein Passwort über die pserver-Methode an, zum Beispiel:

       cvs -d:pserver:someuser:somepassword@server:/path/repo.git co <HEAD_name>

    Für den SSH-Zugriff ist keine spezielle Einrichtung erforderlich, außer dass Git-Tools im PATH sind. Wenn du Clients hast, die die Umgebungsvariable CVS_SERVER nicht akzeptieren, kannst du git-cvsserver in cvs umbenennen.

    Hinweis: Neuere CVS-Versionen (>= 1.12.11) unterstützen auch die Angabe von CVS_SERVER direkt in CVSROOT wie folgt:

       cvs -d ":ext;CVS_SERVER=git cvsserver:user@server/path/repo.git" co <HEAD_name>

    Dies hat den Vorteil, dass es in deinen CVS/Root-Dateien gespeichert wird und du dich nicht darum kümmern musst, immer die richtige Umgebungsvariable zu setzen. SSH-Benutzer, die auf git-shell beschränkt sind, müssen den Standardwert nicht mit CVS_SERVER überschreiben (und sollten es auch nicht), da git-shell cvs als git-cvsserver versteht und so tut, als ob das andere Ende den echten cvs besser ausführt.

  2. Für jedes Repository, das du über CVS zugänglich machen möchtest, musst du die Konfiguration im Repository bearbeiten und den folgenden Abschnitt hinzufügen.

       [gitcvs]
        enabled=1
        # optional for debugging
	logFile=/path/to/logfile

    Hinweis: Du musst sicherstellen, dass jeder Benutzer, der git-cvsserver aufrufen wird, Schreibzugriff auf die Protokolldatei und die Datenbank hat (siehe Datenbank-Backend. Wenn du Schreibzugriff über SSH anbieten möchtest, benötigen die Benutzer natürlich auch Schreibzugriff auf das Git-Repository selbst.

    Du musst auch sicherstellen, dass jedes Repository "bare" ist (ohne Git-Indexdatei), damit cvs commit funktioniert. Siehe gitcvs-migration[7].

    Alle Konfigurationsvariablen können auch pro Zugriffsmethode überschrieben werden. Gültige Methodennamen sind "ext" (für SSH-Zugriff) und "pserver". Das folgende Beispielkonfiguration würde pserver-Zugriff deaktivieren, während der Zugriff über SSH weiterhin erlaubt wäre.

       [gitcvs]
        enabled=0

   [gitcvs "ext"]
        enabled=1

  3. Wenn du CVSROOT/CVS_SERVER nicht direkt im Checkout-Befehl angegeben hast und es automatisch in deinen CVS/Root-Dateien gespeichert wird, musst du sie explizit in deiner Umgebung setzen. CVSROOT sollte wie üblich gesetzt werden, aber das Verzeichnis sollte auf das entsprechende Git-Repository zeigen. Wie oben erwähnt, sollte für SSH-Clients, die nicht auf git-shell beschränkt sind, CVS_SERVER auf git-cvsserver gesetzt werden.

       export CVSROOT=:ext:user@server:/var/git/project.git
   export CVS_SERVER="git cvsserver"

  4. Stelle für SSH-Clients, die Commits durchführen, sicher, dass ihre serverseitigen .ssh/environment-Dateien (oder .bashrc usw., je nach ihrer spezifischen Shell) geeignete Werte für GIT_AUTHOR_NAME, GIT_AUTHOR_EMAIL, GIT_COMMITTER_NAME und GIT_COMMITTER_EMAIL exportieren. Für SSH-Clients, deren Login-Shell bash ist, kann .bashrc eine vernünftige Alternative sein.

  5. Clients sollten nun in der Lage sein, das Projekt auszuchecken. Verwende den CVS-Modulnamen, um anzugeben, welchen Git-Head du auschecken möchtest. Dies setzt auch den Namen deines neu ausgecheckten Verzeichnisses, es sei denn, du gibst dies mit -d <verzeichnis-name> anders an. Zum Beispiel wird hier der master-Branch im Verzeichnis projekt-master ausgecheckt

       cvs co -d project-master master

DATENBANK-BACKEND

git-cvsserver verwendet eine Datenbank pro Git-Head (d. h. CVS-Modul), um Informationen über das Repository zu speichern und konsistente CVS-Revisionsnummern zu erhalten. Die Datenbank muss nach jedem Commit aktualisiert werden (d. h. beschrieben).

Wenn der Commit direkt mit git durchgeführt wird (im Gegensatz zur Verwendung von git-cvsserver), muss die Aktualisierung beim nächsten Repository-Zugriff durch git-cvsserver erfolgen, unabhängig von der Zugriffsmethode und der angeforderten Operation.

Das bedeutet, dass git-cvsserver auch dann Schreibzugriff auf die Datenbank haben sollte, wenn du nur Lesezugriff anbietest (z. B. über die pserver-Methode), um zuverlässig zu funktionieren (andernfalls musst du sicherstellen, dass die Datenbank bei jeder Ausführung von git-cvsserver auf dem neuesten Stand ist).

Standardmäßig verwendet es SQLite-Datenbanken im Git-Verzeichnis mit dem Namen gitcvs.<modul-name>.sqlite. Beachte, dass das SQLite-Backend beim Schreiben temporäre Dateien im selben Verzeichnis wie die Datenbankdatei erstellt, sodass es möglicherweise nicht ausreicht, den Benutzern, die git-cvsserver verwenden, Schreibzugriff auf die Datenbankdatei zu gewähren, ohne ihnen auch Schreibzugriff auf das Verzeichnis zu gewähren.

Die Datenbank kann nach Änderungen am verfolgten Branch nicht zuverlässig in konsistenter Form neu generiert werden. Beispiel: Für zusammengeführte Branches verfolgt git-cvsserver nur einen Entwicklungszweig, und nach einem git merge kann eine inkrementell aktualisierte Datenbank einen anderen Branch verfolgen als eine von Grund auf neu generierte Datenbank, was zu inkonsistenten CVS-Revisionsnummern führt. git-cvsserver weiß nicht, welchen Branch es ausgewählt hätte, wenn es inkrementell vor dem Merge ausgeführt worden wäre. Wenn du die Datenbank also vollständig oder teilweise (aus einem alten Backup) neu generieren musst, solltest du bei bereits vorhandenen CVS-Sandboxes misstrauisch sein.

Du kannst das Datenbank-Backend mit den folgenden Konfigurationsvariablen konfigurieren:

Konfigurieren des Datenbank-Backends

git-cvsserver verwendet das Perl DBI-Modul. Bitte lies auch dessen Dokumentation, wenn du diese Variablen änderst, insbesondere bezüglich DBI->connect().

gitcvs.dbName

Datenbankname. Die genaue Bedeutung hängt vom ausgewählten Datenbanktreiber ab, für SQLite ist dies ein Dateiname. Unterstützt Variablensubstitution (siehe unten). Darf keine Semikolons (;) enthalten. Standard: %Ggitcvs.%m.sqlite

gitcvs.dbDriver

Verwendeter DBI-Treiber. Du kannst hier jeden verfügbaren Treiber angeben, aber er funktioniert möglicherweise nicht. cvsserver wird mit DBD::SQLite getestet, soll mit DBD::Pg funktionieren und angeblich **nicht** mit DBD::mysql. Betrachte dies als experimentelle Funktion. Darf keine Doppelpunkte (:) enthalten. Standard: SQLite

gitcvs.dbuser

Datenbankbenutzer. Nur nützlich, wenn dbDriver gesetzt ist, da SQLite keine Datenbankbenutzer kennt. Unterstützt Variablensubstitution (siehe unten).

gitcvs.dbPass

Datenbankpasswort. Nur nützlich, wenn dbDriver gesetzt ist, da SQLite keine Datenbankpasswörter kennt.

gitcvs.dbTableNamePrefix

Präfix für Datenbanktabellennamen. Unterstützt Variablensubstitution (siehe unten). Alle nicht-alphabetischen Zeichen werden durch Unterstriche ersetzt.

Alle Variablen können auch pro Zugriffsmethode gesetzt werden, siehe oben.

Variablensubstitution

In dbDriver und dbUser kannst du die folgenden Variablen verwenden:

%G

Name des Git-Verzeichnisses

%g

Name des Git-Verzeichnisses, wobei alle Zeichen außer alphanumerischen, . und - durch _ ersetzt werden (dies sollte die Verwendung des Verzeichnisnamens in einem Dateinamen erleichtern, falls gewünscht)

%m

CVS-Modul-/Git-Head-Name

%a

Zugriffsmethode (eine von "ext" oder "pserver")

%u

Name des Benutzers, der git-cvsserver ausführt. Wenn kein Name ermittelt werden kann, wird die numerische uid verwendet.

UMGEBUNG

Diese Variablen machen in einigen Fällen Befehlszeilenoptionen überflüssig und ermöglichen eine einfachere eingeschränkte Nutzung über git-shell.

GIT_CVSSERVER_BASE_PATH

Diese Variable ersetzt das Argument für --base-path.

GIT_CVSSERVER_ROOT

Diese Variable gibt ein einzelnes Verzeichnis an, das die Argumentliste <Verzeichnis>... ersetzt. Das Repository erfordert weiterhin die Konfigurationsoption gitcvs.enabled, es sei denn, --export-all wird angegeben.

Wenn diese Umgebungsvariablen gesetzt sind, dürfen die entsprechenden Befehlszeilenargumente nicht verwendet werden.

HINWEISE ZUM ECLIPSE CVS CLIENT

Um einen Checkout mit dem Eclipse CVS-Client durchzuführen:

  1. Wähle "Neues Projekt erstellen → Aus CVS-Checkout"

  2. Erstelle einen neuen Speicherort. Siehe die nachstehenden Hinweise, um Details zur Auswahl des richtigen Protokolls zu erhalten.

  3. Durchsuche die verfügbaren Module. Es wird eine Liste der Heads im Repository angezeigt. Du kannst den Baum von dort aus nicht durchsuchen. Nur die Heads.

  4. Wähle HEAD, wenn nach dem zu checkoutenden Branch/Tag gefragt wird. Deaktiviere den "Commit-Assistenten starten", um das .project-File nicht zu committen.

Hinweise zum Protokoll: Wenn du anonymen Zugriff über pserver verwendest, wähle einfach diesen aus. Benutzer, die SSH-Zugriff verwenden, sollten das ext-Protokoll wählen und den ext-Zugriff im Bereich „Präferenzen → Team → CVS → ExtConnection“ konfigurieren. Setze CVS_SERVER auf "git cvsserver". Beachte, dass die Passwortunterstützung bei der Verwendung von ext nicht gut ist. Du möchtest auf jeden Fall SSH-Schlüssel eingerichtet haben.

Alternativ kannst du auch einfach das nicht standardmäßige extssh-Protokoll verwenden, das Eclipse anbietet. In diesem Fall wird CVS_SERVER ignoriert, und du musst das cvs-Dienstprogramm auf dem Server durch git-cvsserver ersetzen oder deine .bashrc so manipulieren, dass der Aufruf von cvs effektiv git-cvsserver aufruft.

BEKANNT FUNKTIONIERENDE CLIENTS

  • CVS 1.12.9 unter Debian

  • CVS 1.11.17 unter MacOSX (aus dem Fink-Paket)

  • Eclipse 3.0, 3.1.2 unter MacOSX (siehe Hinweise zum Eclipse CVS Client)

  • TortoiseCVS

UNTERSTÜTZTE OPERATIONEN

Alle für den normalen Gebrauch erforderlichen Operationen werden unterstützt, einschließlich Checkout, Diff, Status, Update, Log, Add, Remove, Commit.

Die meisten CVS-Befehlsargumente, die CVS-Tags oder Revisionsnummern lesen (typischerweise -r), funktionieren und unterstützen auch beliebige Git-Refspecs (Tag, Branch, Commit-ID usw.). Allerdings sind CVS-Revisionsnummern für Nicht-Standard-Branches nicht gut emuliert, und cvs log zeigt keinerlei Tags oder Branches an. (Nicht-Main-Branch-CVS-Revisionsnummern ähneln oberflächlich CVS-Revisionsnummern, aber sie kodieren tatsächlich direkt eine Git-Commit-ID anstatt die Anzahl der Revisionen seit dem Verzweigungspunkt darzustellen.)

Beachte, dass es zwei Möglichkeiten gibt, einen bestimmten Branch auszuchecken. Wie an anderer Stelle auf dieser Seite beschrieben, wird der "Modul"-Parameter von cvs checkout als Branch-Name interpretiert und wird zum Hauptbranch. Er bleibt für ein gegebenes Sandbox der Hauptbranch, auch wenn du mit cvs update -r vorübergehend einen anderen Branch als "sticky" festlegst. Alternativ kann das Argument -r einen anderen Branch angeben, der tatsächlich ausgecheckt werden soll, auch wenn das Modul immer noch der "Haupt"-Branch ist. Kompromisse (wie derzeit implementiert): Jeder neue "Modul" erstellt eine neue Datenbank auf der Festplatte mit einer Historie für das gegebene Modul, und nach der Erstellung der Datenbank sind Operationen gegen diesen Hauptbranch schnell. Oder alternativ verbraucht -r keinen zusätzlichen Speicherplatz, kann aber für viele Operationen wie cvs update erheblich langsamer sein.

Wenn du auf einen Git-Refspec verweisen möchtest, der Zeichen enthält, die von CVS nicht erlaubt sind, hast du zwei Möglichkeiten. Erstens kann es funktionieren, den Git-Refspec direkt an das entsprechende CVS -r-Argument zu übergeben; einige CVS-Clients scheinen keine umfassende Überprüfung des Arguments durchzuführen. Zweitens, wenn das fehlschlägt, kannst du einen speziellen Escape-Mechanismus verwenden, der nur Zeichen verwendet, die in CVS-Tags gültig sind. Eine Sequenz von 4 oder 5 Zeichen der Form (Unterstrich ("_"), Bindestrich ("-"), ein oder zwei Zeichen und Bindestrich ("-")) kann verschiedene Zeichen basierend auf den ein oder zwei Buchstaben kodieren: "s" für Schrägstrich ("/"), "p" für Punkt ("."), "u" für Unterstrich ("_") oder zwei Hexadezimalziffern für jeden beliebigen Byte-Wert (typischerweise eine ASCII-Nummer oder vielleicht ein Teil eines UTF-8-kodierten Zeichens).

Alte Überwachungsoperationen werden nicht unterstützt (edit, watch und verwandte). Exporte und Tagging (Tags und Branches) werden in diesem Stadium nicht unterstützt.

CRLF-Zeilenende-Konvertierungen

Standardmäßig lässt der Server den Modus -k für alle Dateien leer, was dazu führt, dass der CVS-Client sie als Textdateien behandelt, die auf einigen Plattformen Zeilenende-Konvertierungen unterliegen.

Du kannst den Server die Zeilenende-Konvertierungsattribute verwenden lassen, um die -k-Modi für Dateien einzustellen, indem du die Konfigurationsvariable gitcvs.usecrlfattr setzt. Weitere Informationen zur Zeilenende-Konvertierung findest du in gitattributes[5].

Alternativ, wenn die Konfiguration gitcvs.usecrlfattr nicht aktiviert ist oder die Attribute keine automatische Erkennung für einen Dateinamen erlauben, verwendet der Server die Konfiguration gitcvs.allBinary für die Standardeinstellung. Wenn gitcvs.allBinary gesetzt ist, werden Dateien, die nicht anderweitig spezifiziert sind, standardmäßig im Modus -kb behandelt. Andernfalls bleibt der -k-Modus leer. Aber wenn gitcvs.allBinary auf "guess" gesetzt ist, wird der richtige -k-Modus basierend auf dem Inhalt der Datei erraten.

Für die beste Konsistenz mit cvs ist es wahrscheinlich am besten, die Standardeinstellungen zu überschreiben, indem gitcvs.usecrlfattr auf true und gitcvs.allBinary auf "guess" gesetzt wird.

ABHÄNGIGKEITEN

git-cvsserver hängt von DBD::SQLite ab.

GIT

Teil der git[1] Suite