Gentoo Logo

Tutoriel CVS de Gentoo Linux

Table des matières :

1.  Introduction

Organisation du tutoriel

Ce tutoriel est découpé en deux parties. La première explique comment utiliser CVS lorsque l'on n'est pas développeur, c'est-à-dire comment récupérer des sources CVS et les garder à jour. La seconde partie vous présente comment utiliser CVS pour développer en vous montrant comment modifier, ajouter, retirer des fichiers sur CVS, ainsi que comment réaliser bien d'autres tâches de développeurs. Si vous ne connaissez rien à CVS, il est recommandé de commencer par lire la première partie, puis la seconde ; si vous avez une petite expérience de CVS, mais que vous allez l'utiliser en tant que véritable développeur pour la première fois, vous trouverez votre bohneur dans la seconde partie (mais vous pouvez aussi avoir envie de parcourir rapidement la première partie).

Qu'est ce que CVS et qu'est ce que ça fait ?

CVS est un système client/serveur qui permet aux développeurs de conserver leurs projets sur un serveur central appelé dépôt (en anglais « CVS repository »). En utilisant les clients CVS et les outils associés, les développeurs peuvent faire des modifications du contenu sur le serveur. En fait, le dépôt CVS conserve chaque changement fait sur chaque fichier, créant ainsi un historique complet de toute l'évolution du développement du projet. Les développeurs peuvent demander des versions antérieures d'un fichier particulier, regarder un historique des modifications et réaliser au besoin plusieurs autres actions utiles.

Le rôle de CVS

Un nombre considérable de projets ont leur propre serveur CVS qui est utilisé par les développeurs du projet comme répertoire central pour tous leurs travaux. Les développeurs apportent quotidiennement des améliorations aux sources dans le dépôt CVS. Souvent, ces développeurs sont dispersés dans le monde entier; CVS leur fournit ainsi les mécanismes nécessaires pour unifier leur projet dans une structure centralisée et cohérente. CVS crée le « liant organisationnel » qui permet à ces développeurs d'améliorer leur code sans se marcher sur les pieds, sans perdre des données importantes ou sans être bloqués par l'impossiblité de mettre à jour certains fichiers critiques.

CVS - les dernières sources du programmeur

Quand les programmeurs sont prêts, ils archivent la version actuelle de leur travail sur CVS dans un fichier tar.gz et publient celui-ci comme une nouvelle version de leur logiciel. Pourtant, parfois, la dernière version officielle n'est pas assez récente pour vous pour diverses raisons. Dans la première partie de ce tutoriel, nous verrons comment utiliser CVS dans ce but : récupérer la version de développement la plus récente et la plus complète des sources pour votre usage personnel.

Installer CVS

Pour installer CVS, tapez simplement emerge cvs :

Exemple de code 1.1 : Installer CVS

# emerge cvs

Le CVSROOT

Avant de commencer, il y a quelques notions fondamentales à connaître. La première est que pour se connecter sur un dépôt CVS, vous devez tout d'abord paramétrer un chemin appelé le CVSROOT (la racine CVS). CVSROOT est une chaîne de caractères, un peu comme une URL, qui dit à la commande cvs où se trouve le dépôt distant et comment on souhaite s'y connecter. Pour rendre les choses plus intéressantes, CVS supporte de nombreux formats pour CVSROOT, selon que le dépôt est local ou distant, et dépendamment de la méthode utilisée pour s'y connecter. Voici quelques exemples de CVSROOT avec des explications...

Une racine CVS locale

Exemple de code 1.2 : Définir la racine du CVS

CVSROOT=/var/cvsroot

C'est un exemple de chemin pour une racine CVS locale. Vous devriez utiliser une telle variable si vous voulez vous connecter à un dépôt local situé dans /var/cvsroot; ou bien, vous pouvez aussi avoir un dépôt local monté via NFS sur /var/cvsroot.

Une racine CVS pour un pserver distant (serveur avec mot de passe)

Exemple de code 1.3 : Définir serveur CVS distant avec mot de passe

CVSROOT=:pserver:cvs@foo.bar.com:/var/cvsroot

Ceci est un exemple de CVSROOT pour un dépôt existant sur l'hôte foo.bar.com et qui réside dans le /var/cvsroot de cette machine. La partie « :pserver: » indique à notre client qu'il doit se connecter à cette machine distante en utilisant le protocole pserver, un protocole incorporé à CVS. Typiquement, les répertoires CVS publics utilisent des pserver pour autoriser l'accès à des utilisateurs anonymes.

Une racine CVS avec accès distant par RSH/SSH

Exemple de code 1.4 : Définir un CVS avec accès via rsh/ssh

CVSROOT=drobbins@foo.bar.com:/data/cvs

Ceci est un exemple de CVSROOT qui utilise le protocole RSH ou SSH. Dans cet exemple, le CVS va accéder au dépôt sur foo.bar.com via le compte drobbins. Si la variable d'environnement CVS_RSH est réglée à « ssh », le client cvs va utiliser SSH pour se connecter, sinon, RSH est utilisé par défaut. L'accès par SSH est plus populaire chez ceux qui aiment la sécurité, mais ni RSH, ni SSH ne permettent l'accès anonyme aux sources. Pour utiliser cette méthode, il faut absolument avoir un compte sur foo.bar.com.

Quelques précisions...

En plus de la racine CVS, vous allez avoir besoin du nom du module (groupe de sources) que vous voulez récupérer ainsi que le mot de passe anonyme que vous devez utiliser pour vous connecter au serveur CVS. À l'inverse des ftp anonymes, il n'y a pas de format « standard » pour les mots de passe anonymes, il faudra donc récupérer les mots de passe spécifiques publiés sur le site web du développeur ou le demander aux développeurs eux-mêmes. Avec ces informations, vous êtes prêt à commencer.

Utiliser CVS, Partie 1

Récupérer des sources se fait en deux temps. Tout d'abord, il faut se connecter au pserver. Ensuite, on récupère les sources avec la commande checkout. Voici un exemple des commandes que l'on peut lancer pour faire un « checkout » des dernières sources de Samba :

Exemple de code 1.5 : Définir la racine du CVS

# export CVSROOT=:pserver:cvs@pserver.samba.org:/cvsroot

Cette première commande règle la variable d'environnement CVSROOT. Si vous ne le faites pas, il faudra faire suivre, à chaque fois, la commande cvs par l'option suivante : -d :pserver:cvs@pserver.samba.org:/cvsroot. Exporter la variable CVSROOT permet d'éviter de la spécifier à chaque fois.

Uiliser CVS, partie 2

Voici les commandes utiles pour récupérer une copie à jour des sources de développement. Vous pouvez sauter le panneau suivant pour lire l'explication de ces commandes, et revenir ensuite :

Exemple de code 1.6 : Extraire les sources du CVS

# cvs login
(Logging in to cvs@pserver.samba.org)
CVS password: (Tapez le mot de passe ici.)

# cvs -z5 co samba
U samba/COPYING
U samba/Manifest
U samba/README
U samba/Read-Manifest-Now
U samba/Roadmap
U samba/WHATSNEW.txt
(C'est juste une partie de la sortie complète de la commande cvs co output.)

Utiliser CVS - l'explication

La première commande cvs (ci-dessus) nous connecte au pserver et la seconde demande à notre client de faire un « checkout » (« co ») du module samba en utilisant une compression de type gzip de niveau 5 (« -z5 ») pour accélérer la transmission sur une connexion lente. Pour chaque nouveau fichier créé localement, cvs affiche « U [fichier] », ce qui indique que ce fichier a bien été mis à jour sur le disque (« Updated »).

Fin du « checkout »

Une fois le « checkout » terminé, vous aurez un répertoire « samba » dans votre répertoire courant. Remarquez d'ailleurs que chaque répertoire contient un nouveau répertoire « cvs » - CVS y stocke plusieurs informations qui peuvent être ignorées sans problème ici. À partir de maintenant, nous n'avons plus à nous inquiéter que la variable CVSROOT soit réglée ou non, parce que les informations sur le dépôt sont stockées dans ces fameux répertoires « cvs » supplémentaires. À savoir : CVSROOT n'est à définir que pour la première connexion et le premier « checkout ».

Mettre les sources à jour

Quand vous en êtes là, vos sources sont récentes. Vous pouvez les compiler et les installer, les parcourir et en faire tout ce que vous voulez.

De temps en temps, vous pouvez avoir envie de synchroniser vos sources déjà récupérées avec la version actuelle sur CVS. Pour ce faire, vous n'avez pas besoin de vous connecter à nouveau au pserver; vos informations d'authentification sont mises en cache par cvs dans les répertoires « CVS » dont j'ai parlé. Il suffit d'entrer dans le répertoire principal des sources (dans notre cas « samba ») et de taper :

Exemple de code 1.7 : Mettre les fichiers locaux à jour

# cvs update -dP

« cvs update » en bref, partie 1

S'il y a des nouveaux fichiers, cvs va afficher une ligne « U [fichier] » pour chaque fichier qu'il met à jour. Si vous avez déjà compilé les sources une fois, vous allez sans doute voir apparaître beaucoup de lignes « ? [fichier] » ; c'est parce que cvs signale qu'ils ne sont pas sur le dépôt distant.

« cvs update » en bref, partie 2

Remarquez d'ailleurs les deux options utilisées pour faire un « cvs update ». « -d » demande à cvs de créer chez vous les nouveaux répertoires qui ont pu être ajoutés au dépôt (ce qui n'est pas le comportement par défaut), et « -P » sert à supprimer tous les répertoires vides de votre copie locale des sources. « -P » est une bonne idée puisque cvs a tendance à récupérer un bon nombre de répertoires vides (utilisés à une époque, puis abandonnés).

Lorsqu'il s'agit juste de récupérer les sources les plus récentes, c'est à peu près tout ce qu'il suffit de savoir sur cvs. La suite concerne plutôt les développeurs.

2.  CVS pour les developpeurs

Modifier des fichiers

En tant que développeur, vous devrez modifier des fichiers sur le serveur CVS. Pour ceci, commencez par faire les changements désirés sur votre copie du dépôt. Ces changements ne se répercutent pas, bien entendu, sur le dépôt distant tant que vous n'avez pas explicitement demandé à cvs de faire une validation (« commit ») de vos modifications. Lorsque vous avez suffisamment testé toutes vos modifications, que vous êtes sûr que tout fonctionne parfaitement, alors vous êtes prêt à envoyer vos modifications sur le dépôt distant. Suivez bien les deux étapes. En premier lieu, mettez vos sources à jour, par la commande suivante :

Exemple de code 2.1 : Mettre les fichiers locaux à jour

# cvs update -dP

CVS fusionne les modifications des autres

Comme on l'a vu plus tôt, « cvs update » va synchroniser vos sources avec celles du dépôt distant. Mais que va-t-il se passer pour vos modifications ? Rassurez-vous, elles ne seront pas perdues ! Si un autre développeur a modifié un fichier que vous n'avez pas modifié, votre fichier local sera mis à jour, et ainsi, tous les fichiers que vous n'aurez pas touchés seront synchronisés avec les fichiers du dépôt CVS.

De plus, si vous avez modifié localement les lignes 1 à 10 d'un fichier, et qu'un autre développeur a supprimé les lignes 40 à 50, ajouté 12 lignes à la fin de ce fichier, puis réalisé une validation avant vous, alors cvs va réaliser une fusion intelligente des modifications réalisées par l'autre développeur sur votre copie, et ainsi, aucun travail n'est perdu. Cela permet à deux développeurs de travailler sur des parties distinctes d'un même fichier en même temps.

La fusion n'est pas parfaite

Pourtant, si deux développeurs ou plus ont fait des modifications sur la même partie du même fichier, alors les choses se compliquent un tout petit peu. Si cela arrive, alors cvs va vous prévenir qu'il y a un conflit. Aucun travail n'est perdu, mais une intervention de votre part va être requise. En effet, cvs a besoin que vous lui indiquiez comment fusionner les changements.

La validation (« commit »)

Nous allons nous intéresser à la résolution des conflits un peu plus loin. Mais pour l'instant, supposons qu'il n'y a pas eu de conflit à la sortie de la commande « cvs update -dP » (ce qui est souvent le cas). Dans ce cas, vos sources locales sont à jour (« up-to-date ») et vous êtes alors prêt à réaliser la validation de vos sources. Il suffit de taper la commande suivante dans le répertoire principal de vos sources :

Exemple de code 2.2 : Valider des modifications

# cvs commit

Ce que fait la validation

« cvs commit » ne fait pas qu'appliquer vos modifications sur le dépôt distant. Avant de vraiment envoyer vos sources, cvs va ouvrir votre éditeur par défaut pour que vous puissiez écrire une courte description des changements réalisés. Une fois ce commentaire saisi, enregistrez le fichier et quittez l'éditeur. Vos changements (et les commentaires associés) vont être appliqués au dépôt distant et vont être disponibles pour les autres développeurs de l'équipe.

Consulter les journaux (« logs »)

Il est vraiment très facile de consulter l'historique complet d'un fichier donné avec tous les commentaires que les développeurs (dont vous) ont pu faire lorsqu'ils ont fait des validations. Pour accéder à ces informations, faites :

Exemple de code 2.3 : Afficher le journal des modifications

# cvs log myfile.c

« cvs log » est une commande récursive, donc pour consulter le log complet de toute une arborescence d'un répertoire, allez dans le répertoire en question et tapez :

Exemple de code 2.4 : Afficher le journal des modifications avec un pagineur

# cvs log | less

Les options de la validation

Vous pourriez avoir envie d'utiliser un autre éditeur que celui que cvs utilise par défaut lorsque vous faites une validation. Si c'est le cas, réglez la variable d'environnement EDITOR sur le nom de votre éditeur favori. Mettre une telle ligne dans votre ~/.bashrc peut être une bonne idée :

Exemple de code 2.5 : Définir l'éditeur à utiliser

export EDITOR=nano

Vous pouvez aussi spécifier le commentaire dans la ligne de commande de sorte que cvs n'ait pas à ouvrir un éditeur de texte :

Exemple de code 2.6 : Donner le commentaire de validation sur la ligne de commande

# cvs commit -m 'Ceci doit être un commentaire intelligent'

Le fichier .cvsrc

Avant de continuer de découvrir d'autres commandes cvs, je vous recommande de créer un fichier ~/.cvsrc. En le créant dans votre répertoire personnel, vous pouvez dire à cvs d'utiliser des options par défaut pour chaque commande cvs, et ainsi, vous n'avez pas à vous rappeler de les taper à chaque fois. Voici un exemple de fichier .cvsrc :

Exemple de code 2.7 : Options par défaut recomandées

cvs -q
diff -u -b -B
checkout -P
update -d -P

Le fichier .cvsrc, suite

En plus de pouvoir spécifier plusieurs options utiles pour un grand nombre de commandes cvs, la première ligne du .cvsrc force le mode silencieux de cvs, ce qui a comme première conséquence de rendre la sortie de « cvs update » beaucoup plus concise et lisible. Une fois ce fichier en place, il vous suffit de taper « cvs update » au lieu de « cvs update -dP » (par exemple).

Ajouter un fichier au dépôt

Il est vraiment facile d'ajouter un fichier source au CVS. En premier lieu, vous devez créer le fichier en question, puis, tapez la commande suivante :

Exemple de code 2.8 : Ajouter un fichier au dépôt

# cvs add myfile.c
cvs server: use 'cvs commit' to add this file permanently

Ceci va dire à cvs d'ajouter ce fichier au dépôt la prochaine fois que vous ferez une validation. Jusqu'à ce moment, les autres développeurs ne pourront pas le voir.

Ajouter un répertoire au dépôt

Pour ajouter un répertoire, la procédure est similaire :

Exemple de code 2.9 : Ajouter un répertoire

# mkdir foo
# cvs add foo
Directory /var/cvsroot/mycode/foo added to the repository

À la différence d'un ajout de fichier, lorsque vous ajoutez un répertoire, il apparaît immédiatement dans le dépôt, la validation n'est pas requise. Une fois le répertoire local ajouté au dépôt, vous allez remarquer qu'un répertoire « cvs » y est créé pour y stocker les informations CVS. Ainsi, vous pouvez facilement savoir si un répertoire a été ajouté à cvs en regardant s'il contient un répertoire « CVS ».

Remarques sur « cvs add »

Comme vous pouvez le deviner, avant d'ajouter un fichier ou un répertoire au dépôt, vous devez bien vérifier que son répertoire parent lui a déjà été ajouté. Sinon, vous aurez l'erreur suivante :

Exemple de code 2.10 : Échec lors de l'ajout d'un fichier

# cvs add myfile.c
cvs add: cannot open CVS/Entries for reading: No such file or directory
cvs [add aborted]: no repository 

Se familiariser avec « cvs update », partie 1

Avant de s'occuper de la résolution des conflits, familiarisons-nous avec les sorties de la commande « cvs update ». Si vous créez un fichier ~/.cvsrc qui contient la ligne « cvs -q », vous allez trouver les sorties de « cvs update » beaucoup plus faciles à lire. « cvs update » vous informe de ce qu'il fait, représentant ses actions par un caractère, un espace et un nom de fichier. Par exemple :

Exemple de code 2.11 : Mise à jour des fichiers locaux

# cvs update -dP
? distfiles
? packages
? profiles

Se familiariser avec « cvs update », partie 2

« cvs update » utilise le caractère « ? » pour vous signifier qu'il ne sait rien sur les fichiers qu'il retrouve dans votre copie locale mais pas sur le dépôt. Ces fichiers ne font pas partie du dépôt distant, et n'ont pas non plus été prévus pour être ajoutés au dépôt. Voici une liste de tous les messages possibles que CVS utilise :

Exemple de code 2.12 : Message d'information: U

U [path]

Utilisé lorsqu'un fichier est créé dans votre copie locale, ou si un fichier que vous n'avez pas touché est mis à jour.

Exemple de code 2.13 : Message d'information: A

A [path]

L'ajout de ce fichier au dépôt a été programmé et sera officiellement ajouté quand vous ferez une validation.

Se familiariser avec « cvs update », partie 3

Exemple de code 2.14 : Message d'information: R

R [path]

À l'image de « A », « R » vous indique que la suppression de ce fichier a été prévue. Ce fichier sera effectivement retiré dès que vous aurez fait une validation.

Exemple de code 2.15 : Message d'information: M

M [path]

Cela signifie que ce fichier a été modifié par vous. Il est possible que des modifications aient été fusionnées dans ce fichier sans conflit.

Exemple de code 2.16 : Message d'information: C

C [path]

Le caractère « C » indique que ce fichier présente des conflits et nécessite une intervention manuelle avant de réaliser votre validation.

Résoudre les conflits, introduction

Désormais, occupons-nous de résoudre ces conflits. Je suis assez impliqué dans le projet Gentoo-Linux et nous avons notre propre serveur cvs configuré sur cvs.gentoo.org. Nous autres, développeurs, passons la majorité de notre temps à hacker les sources du module « gentoo-x86 » et nous avons ajouté un fichier appelé « ChangeLog » qui contient (vous l'aurez deviné) les modifications majeures que nous avons faites sur le dépôt.

Un exemple de conflit

Puisque ce ficher est modifié à peu près à chaque fois qu'un changement majeur est réalisé sur CVS, c'est notre plus grande source de conflits. En voici un exemple. Imaginons que j'ai ajouté les lignes suivantes au début du fichier de ChangeLog :

Exemple de code 2.17 : Commentaire de validation

date 25 Feb 2001

J'ai ajouté ce commentaire

Imaginons qu'avant que je ne fasse une validation de ces trois nouvelles lignes, un développeur avait déja ajouté les lignes suivantes au début du Changelog et envoyé ses modifications :

Exemple de code 2.18 : Commentaire de validation 2

date 25 Feb 2001

Un autre développeur a ajouté ce commentaire

Une exemple de conflit, suite

Maintenant, lorsque je fais un « cvs update -dP » (comme il faut le faire avant chaque validation), cvs n'est pas capable de fusionner ces modifications sur ma copie locale du ChangeLog parce que nous avons tous les deux ajouté des lignes dans la même partie du fichier. CVS ne sait alors pas quelle partie utiliser. Ainsi, j'ai l'erreur suivante :

Exemple de code 2.19 : Erreur CVS en cas de conflit

RCS file: /var/cvsroot/gentoo-x86/ChangeLog,v
retrieving revision 1.362
retrieving revision 1.363
Merging differences between 1.362 and 1.363 into ChangeLog
rcsmerge: warning: conflicts during merge
cvs server: conflicts found in ChangeLog
C ChangeLog

Résolution de conflit, partie 1

Ahhh, un conflit ! Heureusement, résoudre un conflit est facile. Si je lance mon éditeur favori, je vois le texte suivant au début du fichier « ChangeLog » :

Exemple de code 2.20 : Texte ajouté par le serveur CVS en cas de conflit

<<<<<<< ChangeLog
date 25 Feb 2001

J'ai ajouté ce commentaire

=======
date 25 Feb 2001

Un autre développeur a ajouté ce commentaire

>>>>>>> 1.363

Résolution de conflit, partie 2

Au lieu de choisir une version ou l'autre, cvs ajoute les deux versions au fichier ChangeLog et les entoure de caractères spéciaux pour marquer clairement les régions qui posent problème. Maintenant, c'est à moi de remplacer ces régions par les textes qui devraient apparaître dans le ChangeLog; dans ce cas, le texte de remplacement n'est ni l'une, ni l'autre des versions, mais une combinaison des deux :

Exemple de code 2.21 : Nouveau commentaire de validation

date 25 Feb 2001

J'ai ajouté ce commentaire

Un autre développeur a ajouté ce commentaire

Maintenant que j'ai remplacé les régions conflictuelles du fichier avec le texte approprié (et supprimé les « ======= » et autres marqueurs), je peux faire une validation sans aucun problème.

Astuces pour résoudre les conflits

À chaque fois que vous avez besoin d'éditer un fichier pour régler des conflits, vérifiez que vous avez bien parcouru tout le fichier de telle manière que vous n'ayez rien oublié. Sinon, cvs n'autorisera pas votre validation et ce jusqu'à ce que le conflit soit résolu. Il est donc très important d'enlever les marqueurs spéciaux que cvs a ajoutés aux fichiers conflictuels. Autre astuce : si vous avez fait une erreur en essayant de résoudre un conflit et que vous avez accidentellement enregistré vos modifications, vous pouvez retrouver la copie originale du fichier dans le fichier « .#nom_du_fichier.version ».

Supprimer un fichier

Maintenant, il est temps de découvrir notre dernière commande cvs : supprimer un fichier du dépôt. Supprimer un fichier se fait en deux étapes. Il faut commencer par supprimer le fichier de votre copie des sources, puis exécuter la commande « cvs remove » sur ce fichier :

Exemple de code 2.22 : Supprimer un fichier

# rm myoldfile.c
# cvs remove myoldfile.c

Supprimer un fichier, suite

La suppression du fichier est alors prévue par cvs et sera effective lors de votre prochaine validation. Une fois la validation réalisée, le fichier sera officiellement supprimé du dépôt distant. Pourtant, cvs ne va pas faire disparaître ce fichier et va garder un enregistrement complet de son contenu et de son historique au cas où vous en auriez besoin dans le futur. C'est juste un des nombreux moyens utilisés par cvs pour protéger votre code.

« cvs remove » est récursif, ce qui signifie que vous pouvez supprimer un ensemble de fichiers et lancer la commande « cvs remove » sans autre argument depuis un répertoire parent. Ceci va marquer tous les fichiers supprimés comme « à supprimer » lors de la prochaine validation.

Supprimer un répertoire

Si vous voulez supprimer un répertoire complet, je vous recommande la méthode suivante. Tout d'abord, supprimez chaque fichier du répertoire et faites un « cvs remove » :

Exemple de code 2.23 : Supprimer un répertoire

# rm *.c
# cvs remove

Supprimer un répertoire, suite

Ensuite, faites une validation :

Exemple de code 2.24 : Validation

# cvs commit

Et là, astuce : exécutez les commandes suivantes pour supprimer le répertoire :

Exemple de code 2.25 : Supprimer un répertoire

# cd ..
# cvs remove mydir
# rm -rf mydir

Remarquez que supprimer un répertoire ne nécessite pas une autre validation. L'ajout et la suppression de répertoires sur le dépôt distant se font en temps réel.

Récupérer une ancienne version

CVS ne serait pas un bon système de gestion de versions si vous ne pouviez pas récupérer d'anciennes versions depuis le dépôt. Ainsi vous pouvez récupérer des fichiers en spécifiant une date, mais également bien sûr avec le numéro de révision. L'exemple suivant récupère la révision 1.202 de monfichier et écrase la version courante de monfichier avec cette version :

Exemple de code 2.26 : Récupération d'un fichier basé sur un numéro de révision

$ cvs update -p -r 1.202 monfichier > monfichier

Si vous voulez récupérer des fichiers en vous basant sur une date, utilisez l'argument -D. Vous pouvez utilisez la date exacte ou le timestamp, mais aussi des noms relatifs comme yesterday (pour « hier ») ou last week (pour « semaine dernière »).

C'est terminé !

Votre introduction à CVS est terminée. J'espère que ce tutoriel vous a été utile. Il y a bien d'autres choses à savoir sur CVS, que je n'ai pu couvrir dans cette introduction, mais heureusement, la volumineuse documentation disponible vous aidera à étendre vos connaissances sur CVS :

À propos de ce document

La version originale de cet article a été publiée sur le site developerWorks d'IBM et est la propriété de Westtech Information Services. Ce document est une mise à jour de l'article original et contient diverses améliorations faites par l'équipe de documentation de Gentoo.



Imprimer

Dernière mise à jour le 20 mai 2008

La version originale de cette traduction n'est plus maintenue

Résumé : Ce tutoriel va présenter le système CVS (Concurrent Versions System) aux lecteurs. CVS est utilisé par beaucoup de développeurs de par le monde pour développer des logiciels de façon collaborative dans un environnement souple. Destiné aux utilisateurs débutants de CVS, ce tutoriel va permettre à la fois aux utilisateurs occasionnels et aux nouveaux développeurs de travailler beaucoup plus efficacement. Que vous désiriez utiliser CVS pour faire un « check out » des dernières sources d'un logiciel donné ou que vous l'utilisiez en tant que développeur expérimenté, ce tutoriel est fait pour vous.

Daniel Robbins
Auteur

Pierre Habouzit
Traducteur

Camille Huot
Traducteur

Xavier Neys
Correcteur, Traducteur

Donate to support our development efforts.

Copyright 2001-2014 Gentoo Foundation, Inc. Questions, Comments? Contact us.