git-cvsserver - Un émulateur de serveur CVS pour Git

SSH :

pserver (/etc/inetd.conf) :

Utilisation :

Cette application est une couche d’émulation CVS pour Git.

Elle est très fonctionnelle. Cependant, toutes les méthodes ne sont pas mises en œuvre, et pour les méthodes qui le sont, tous les drapeaux ne sont pas mis en œuvre.

Les tests ont été effectués en utilisant à la fois le client en ligne de commande CVS et le plugin CVS Eclipse. La plupart des fonctionnalités fonctionnent bien avec ces deux clients.

Toutes ces options n’ont évidemment de sens que si elles sont appliquées du côté du serveur. Elles ont été implémentées pour ressembler le plus possible aux options de git-daemon[1].

Les clients CVS ne peuvent pas étiqueter, faire des branches ou effectuer des fusions Git.

git-cvsserver fait correspondre les branches Git aux modules CVS. C’est très différent de ce à quoi la plupart des utilisateurs de CVS s’attendent puisque dans CVS, les modules représentent généralement un ou plusieurs répertoires.

git-cvsserver utilise une base de données par tête Git (c’est-à-dire le module CVS) pour stocker des informations sur le dépôt afin de maintenir des numéros de révision CVS cohérents. La base de données doit être mise à jour (c’est-à-dire écrite) après chaque validation.

Si le commit est effectué directement en utilisant git (par opposition à l’utilisation de git-cvsserver), la mise à jour devra se produire lors du prochain accès au dépôt par git-cvsserver, indépendamment de la méthode d’accès et de l’opération demandée.

Cela signifie que même si vous n’offrez qu’un accès en lecture (par exemple en utilisant la méthode pserver), git-cvsserver doit avoir un accès en écriture à la base de données pour fonctionner de manière fiable (sinon vous devez vous assurer que la base de données est à jour à chaque fois que git-cvsserver est exécuté).

Par défaut, il utilise des bases de données SQLite dans le répertoire Git, nommées gitcvs.<nom-de-module>.sqlite. Notez que le moteur SQLite crée des fichiers temporaires dans le même répertoire que le fichier de base de données lors de l’écriture. Il pourrait donc ne pas être suffisant d’accorder aux utilisateurs utilisant git-cvsserver un accès en écriture au fichier de base de données sans leur accorder également un accès en écriture au répertoire.

La base de données ne peut pas être régénérée de manière fiable sous une forme cohérente après que la branche qu’elle suit a changé. Exemple : pour les branches fusionnées, git-cvsserver ne suit qu’une branche de développement, et après un git merge une base de données mise à jour de manière incrémentielle peut suivre une branche différente de celle d’une base de données régénérée à partir de zéro, ce qui entraîne des numéros de révision CVS incohérents. git-cvsserver n’a aucun moyen de savoir quelle branche il aurait choisie s’il avait été lancé de manière incrémentale avant la fusion. Donc si vous devez régénérer entièrement ou partiellement (à partir d’une ancienne sauvegarde) la base de données, vous devez vous méfier des bacs à sable CVS préexistants.

Vous pouvez configurer le moteur de la base de données avec les variables de configuration suivantes :

Ces variables rendent inutile l’utilisation d’options en ligne de commande dans certaines circonstances, ce qui permet un usage restreint plus facile via git-shell.

Lorsque ces variables d’environnement sont définies, les arguments de ligne de commande correspondants peuvent ne pas être utilisés.

Pour obtenir une extraction avec le client CVS d’Eclipse :

Notes sur le protocole : si vous utilisez un accès anonyme via pserver, il suffit de le sélectionner. Ceux qui utilisent un accès SSH doivent choisir le protocole ext et configurer l’accès ext dans le panneau Preferences→Team→CVS→ExtConnection. Définissez CVS_SERVER à "git cvsserver". Notez que la prise en charge des mots de passe n’est pas bonne lorsque vous utilisez ext vous voudrez certainement avoir des clés SSH configurées.

Alternativement, vous pouvez simplement utiliser le protocole non standard extssh que Eclipse propose. Dans ce cas, CVS_SERVER est ignoré, et vous devrez remplacer l’utilitaire cvs sur le serveur par git-cvsserver ou manipuler votre .bashrc pour que l’appel à cvs appelle effectivement git-cvsserver.

Toutes les opérations nécessaires à une utilisation normale sont prises en charge, y compris l’extraction, la comparaison, l’état, la mise à jour, le journal, l’ajout, la suppression et la validation.

La plupart des arguments de commande CVS qui lisent les étiquettes CVS ou les numéros de révision (typiquement -r) fonctionnent, et supportent également n’importe quel spécificateur de référence git (étiquette, branche, ID de commit, etc). Cependant, les numéros de révision CVS pour les branches non-définies par défaut ne sont pas bien émulés, et cvs log n’affiche pas du tout les étiquettes ou les branches. (Les numéros de révision CVS des branches non principales ressemblent superficiellement aux numéros de révision CVS, mais ils encodent en fait directement un ID de commit git, plutôt que de représenter le nombre de révisions depuis le point de branchement).

Notez qu’il y a deux façons d’extraire une branche particulière. Comme décrit ailleurs sur cette page, le paramètre "module" de cvs checkout est interprété comme un nom de branche, et il devient la branche principale. Elle reste la branche principale pour un bac à sable donné même si vous rendez temporairement une autre branche collante avec cvs update -r. Alternativement, l’argument -r peut indiquer une autre branche à vérifier, même si le module est toujours la branche "principale". Compromis (tel qu’implémenté actuellement) : chaque nouveau "module" crée une nouvelle base de données sur le disque avec un historique pour le module donné, et après la création de la base de données, les opérations sur cette branche principale sont rapides. Ou alternativement, -r ne prend pas d’espace disque supplémentaire, mais peut être significativement plus lent pour de nombreuses opérations, comme cvs update.

Si vous voulez faire référence à une spécification de référence git qui contient des caractères non autorisés par CVS, vous avez deux options. Premièrement, il est possible de fournir la spécification de référence git directement à l’argument CVS -r approprié ; certains clients CVS ne semblent pas faire beaucoup de vérification de l’intégrité de l’argument. Deuxièmement, si cela échoue, vous pouvez utiliser un mécanisme spécial d’échappement de caractères qui n’utilise que les caractères valides dans les étiquettes CVS. Une séquence de 4 ou 5 caractères de la forme (trait de soulignement ("_"), tiret ("-"), un ou deux caractères, et tiret ("-")) peut coder divers caractères basés sur les une ou deux lettres : "s" pour la barre oblique ("/"), "p" pour le point (" ."), "u" pour le trait de soulignement ("_"), ou deux chiffres hexadécimaux pour toute valeur d’octet (typiquement un nombre ASCII, ou peut-être une partie d’un caractère codé UTF-8).

Les anciennes opérations de surveillance ne sont pas prises en charge (édition, surveillance et connexes). Les exportations et l’étiquetage (étiquettes et branches) ne sont pas supportés à ce stade.

git-cvsserver dépend de DBD::SQLite.

Fait partie de la suite git[1]

Cette page de manuel a été traduite par Jean-Noël Avila <jn.avila AT free DOT fr> et les membres du projet git-manpages-l10n. Veuillez signaler toute erreur de traduction par un rapport de bogue sur le site https://github.com/jnavila/git-manpages-l10n .