Attachment #26623 for bug #43324

View | Details | Raw Unified | Return to bug 43324
Collapse All | Expand All





<guide link="/doc/fr/cvs-tutorial.xml">
<title>Tutoriel CVS de Gentoo Linux</title>
<author title="Architecte principal"> <mail link="drobbins@gentoo.org">Daniel Robbins</mail></author>
<author title="Traducteur"> <mail link="pierre.habouzit@m4x.org">Pierre Habouzit</mail></author>
<author title="Traducteur"> <mail link="cam@cameuh.net">Camille Huot</mail></author>
<author title="Traducteur"> <mail link="neysx@gentoo.org">Xavier Neys</mail></author>

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 «&nbsp;check
out&nbsp;» 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.
</abstract>


<title>Introduction</title>

<section>
<title>Organisation du tutoriel</title>
<body>
    <p>
        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&nbsp;; 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).

<body>
    <p>
        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 «&nbsp;CVS 
        repository&nbsp;»). 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.
    </p>
</body>
</section>

<title>Le rôle de CVS</title>
<body>
    <p>
        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 «&nbsp;liant organisationnel&nbsp;» 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.
    </p>
</body>
</section>

<section>
<title>CVS - les dernières sources du programmeur</title>
<body>
    <p>
        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.
    </p>

</section>

<section>
<title>CVS - l'avez vous ?</title>
<body>
    <p>
        Avant que vous ne puissiez utiliser CVS, vous devez l'installer sur votre système.
        Le moyen le plus simple de vérifier si CVS est installé sur votre système est de taper :
    </p>
<pre>
# <i>cvs</i>
</pre>
    <p>
        Si la commande cvs est trouvée, alors vous l'avez. Sinon, vous devez soit récupérer
        un paquet binaire pour votre distribution, soit l'installer depuis les sources.
        Installer CVS depuis les sources est plutôt simple et je vous montre comment le
        faire ci-dessous.
    </p>

    <p>
        Installer CVS depuis les sources est facile. Tout d'abord, récupérez le tarball
        cvs-1.11.tar.gz depuis <uri>ftp://ftp.cvshome.org/pub/cvs-1.11/cvs-1.11.tar.gz</uri>
        (s'il y a une version plus récente répertoriée <uri link="ftp://ftp.cvshome.org/pub/">ici</uri>,
        vous pouvez aussi bien récupérer la nouvelle à la place). Ensuite, procédez comme suit (la sortie
        standard a été omise) :
    </p>

<title>Le CVSROOT</title>
<body>
    <p>
        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...
    </p>
</body>
</section>

    <pre>CVSROOT=/home/cvsroot</pre>
    <p>
        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 /home/cvsroot; ou bien, vous pouvez aussi avoir un dépôt local
        monté via NFS sur /home/cvsroot.
    </p>
</body>
</section>

<body>
    <pre>CVSROOT=:pserver:cvs@foo.bar.com:/home/cvsroot</pre>
    <p>
        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 /home/cvsroot de cette machine.
        La partie «&nbsp;:pserver:&nbsp;» 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.

</section>

<section>
<title>Une racine CVS avec accès distant par RSH/SSH</title>
<body>
    <pre>CVSROOT=drobbins@foo.bar.com:/data/cvs</pre>
    <p>
        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 à «&nbsp;ssh&nbsp;», 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.
    </p>

        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 «&nbsp;standard&nbsp;»
        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.

    <p>
        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 <c>checkout</c>.
        Voici un exemple des commandes que l'on peut lancer pour faire un «&nbsp;checkout&nbsp;»
        des dernières sources de Samba :
    </p>
<pre>
# <i>export CVSROOT=:pserver:cvs@pserver.samba.org:/cvsroot</i>
</pre>
    <p>
        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 <c>cvs</c>
        par l'option suivante&nbsp;: <c>-d :pserver:cvs@pserver.samba.org:/cvsroot</c>.
        Exporter la variable CVSROOT permet d'éviter de la spécifier à chaque fois.
    </p>
</body>
</section>

<pre>
# <i>cvs login</i>
(Logging in to cvs@pserver.samba.org)
CVS password: <comment>(Tapez le mot de passe ici.)</comment>

# <i>cvs -z5 co samba</i>
U samba/COPYING

U samba/Read-Manifest-Now
U samba/Roadmap
U samba/WHATSNEW.txt
<comment>(C'est juste une partie de la sortie complète de la commande cvs co output.)</comment>
</pre>

</body>
</section>

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

<section>
<title>Fin du «&nbsp;checkout&nbsp;»</title>
<body>
    <p>
        Une fois le «&nbsp;checkout&nbsp;» terminé, vous aurez un répertoire 
        «&nbsp;samba&nbsp;» dans votre répertoire courant. Remarquez d'ailleurs que chaque 
        répertoire contient un nouveau répertoire «&nbsp;cvs&nbsp;» - 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 «&nbsp;cvs&nbsp;» supplémentaires. À savoir : CVSROOT n'est à
        définir que pour la première connexion et le premier «&nbsp;checkout&nbsp;».
    </p>
</body>
</section>

        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 «&nbsp;CVS&nbsp;» dont j'ai parlé. Il suffit d'entrer dans le répertoire
        principal des sources (dans notre cas «&nbsp;samba&nbsp;») et de taper :
    </p>
<pre>
# <i>cvs update -dP</i>

</section>

<section>
<title>«&nbsp;cvs update&nbsp;» en bref, partie 1</title>
<body>
    <p>
        S'il y a des nouveaux fichiers, cvs va afficher une ligne «&nbsp;U [fichier]&nbsp;»
        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
        «&nbsp;? [fichier]&nbsp;» ; c'est parce que cvs signale qu'ils ne sont pas 
        sur le dépôt distant.
    </p>
</body>
</section>

<section>
<title>«&nbsp;cvs update&nbsp;» en bref, partie 2</title>
<body>
    <p>
        Remarquez d'ailleurs les deux options utilisées pour faire un «&nbsp;cvs update&nbsp;».
        «&nbsp;-d&nbsp;» 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 «&nbsp;-P&nbsp;»
        sert à supprimer tous les répertoires vides de votre copie locale des sources.
        «&nbsp;-P&nbsp;» 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).
    </p>
    <p>

<body>
    <p>
        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 un «&nbsp;commit&nbsp;» 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 :
    </p>
<pre>

<title>CVS fusionne les modifications des autres</title>
<body>
    <p>
        Comme on l'a vu plus tôt, «&nbsp;cvs update&nbsp;» 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.
    </p>
    <p>
        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é un «&nbsp;commit&nbsp;» 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.
    </p>
</body>



<section>
<title>Le «&nbsp;commit&nbsp;»</title>
<body>
    <p>
        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 «&nbsp;cvs update -dP&nbsp;» (ce qui est souvent le cas). Dans ce cas, vos
        sources locales sont à jour («&nbsp;up-to-date&nbsp;») et vous êtes alors prêt à 
        réaliser le «&nbsp;commit&nbsp;» de vos sources. Il suffit de taper la commande 
        suivante dans le répertoire principal de vos sources :
    </p>
<pre>
# <i>cvs commit</i>

</section>

<section>
<title>Ce que fait le «&nbsp;commit&nbsp;»</title>
<body>
    <p>
        «&nbsp;cvs commit&nbsp;» ne fait <i>pas qu'appliquer</i> 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.
    </p>
</body>
</section>

<section>
<title>Consulter les journaux («&nbsp;logs&nbsp;»)</title>
<body>
    <p>
        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 «&nbsp;commit&nbsp;». Pour accéder à ces informations, 
        faites :
    </p>
<pre>
# <i>cvs log myfile.c</i>
</pre>
    <p>
        «&nbsp;cvs log&nbsp;» 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 :
    </p>
<pre>
# <i>cvs log | less</i>

</section>

<section>
<title>Les options du «&nbsp;commit&nbsp;»</title>
<body>
    <p>
        Vous pourriez avoir envie d'utiliser un autre éditeur que celui que cvs utilise par défaut
        lorsque vous faites un «&nbsp;cvs commit&nbsp;». 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 :
    </p>

<body>
    <p>
        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 :
    </p>
<pre>
cvs -q

<title>Le fichier .cvsrc, suite</title>
<body>
    <p>
        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 «&nbsp;cvs update&nbsp;» beaucoup 
        plus concise et lisible. Une fois ce fichier en place, il vous suffit de taper
        «&nbsp;cvs update&nbsp;» au lieu de «&nbsp;cvs update -dP&nbsp;» (par exemple).
    </p>
</body>
</section>

<section>
<title>Ajouter un fichier au dépôt</title>
<body>
    <p>
        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 :
    </p>
<pre>
# <i>cvs add myfile.c</i>
cvs server: use 'cvs commit' to add this file permanently
</pre>
    <p>
        Ceci va dire à cvs d'ajouter ce fichier au dépôt la prochaine fois
        que vous ferez un «&nbsp;cvs commit&nbsp;». Jusqu'à ce moment, les autres développeurs
        ne pourront pas le voir.
    </p>
</body>
</section>

<section>
<title>Ajouter un répertoire au dépôt</title>
<body>
    <p>
        Pour ajouter un répertoire, la procédure est similaire :

<pre>
# <i>mkdir foo</i>
# <i>cvs add foo</i>
Directory /home/cvsroot/mycode/foo added to the dépôt   
</pre>
    <p>
        À la différence d'un ajout de fichier, lorsque vous ajoutez un répertoire,
        il apparaît immédiatement dans le dépôt, le «&nbsp;commit&nbsp;» n'est pas requis.
        Une fois le répertoire local ajouté au dépôt, vous allez remarquer
        qu'un répertoire «&nbsp;cvs&nbsp;» 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 «&nbsp;CVS&nbsp;».
    </p>
</body>
</section>

<section>
<title>Remarques sur «&nbsp;cvs add&nbsp;»</title>
<body>
    <p>
        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 :
    </p>
<pre>

</section>

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

</section>

<section>
<title>Se familiariser avec «&nbsp;cvs update&nbsp;», partie 2</title>
<body>
    <p>
        «&nbsp;cvs update&nbsp;» utilise le caractère «&nbsp;?&nbsp;» 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 :
    </p>
<pre>
U [path]

A [path]
</pre>
    <p>
        L'ajout de ce fichier au dépôt a été programmé et sera officiellement ajouté
        quand vous ferez un «&nbsp;cvs commit&nbsp;».
    </p>
</body>
</section>


<section>
<title>Se familiariser avec «&nbsp;cvs update&nbsp;», partie 3</title>
<body>
<pre>
R [path]
</pre>
    <p>
        À l'image de «&nbsp;A&nbsp;», «&nbsp;R&nbsp;» vous indique que la 
        suppression de ce fichier a été prévue. Ce fichier sera effectivement 
        retiré dès que vous aurez fait un «&nbsp;cvs commit&nbsp;».
    </p>
<pre>
M [path]
</pre>
    <p>
        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.
    </p>
<pre>
C [path]
</pre>
    <p>
        Le caractère «&nbsp;C&nbsp;» indique que ce fichier présente des conflits 
        et nécessite une intervention manuelle avant de réaliser votre 
        «&nbsp;commit&nbsp;».
    </p>
</body>
</section>

        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 «&nbsp;gentoo-x86&nbsp;» et nous avons ajouté un 
        fichier appelé «&nbsp;ChangeLog&nbsp;» qui contient (vous l'aurez deviné) les 
        modifications majeures que nous avons faites sur le dépôt.
    </p>
</body>
</section>

J'ai ajouté ce commentaire
</pre>
    <p>
        Imaginons qu'avant que je ne fasse un «&nbsp;commit&nbsp;» de ces trois nouvelles 
        lignes, un développeur avait déja ajouté les lignes suivantes au début du Changelog et
        envoyé ses modifications :
    </p>
<pre>

<title>Une exemple de conflit, suite</title>
<body>
    <p>
        Maintenant, lorsque je fais un «&nbsp;cvs update -dP&nbsp;» (comme il faut 
        le faire avant chaque commit), 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 :
    </p>
<pre>

<body>
    <p>
        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 
        «&nbsp;ChangeLog&nbsp;» :
    </p>
<pre>
&lt;&lt;&lt;&lt;&lt;&lt;&lt; ChangeLog

<pre>
date 25 Feb 2001

J'ai ajouté ce commentaire

Un autre développeur a ajouté ce commentaire
</pre>
    <p>
        Maintenant que j'ai remplacé les régions conflictuelles du fichier avec le texte
        approprié (et supprimé les «&nbsp;=======&nbsp;» et autres marqueurs), je peux faire
        un «&nbsp;commit&nbsp;» sans aucun problème.
    </p>
</body>
</section>

<title>Astuces pour résoudre les conflits</title>
<body>
    <p>
        À 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 «&nbsp;commit&nbsp;» 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 «&nbsp;.#nom_du_fichier.version&nbsp;».
    </p>
</body>
</section>

<body>
    <p>
        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 «&nbsp;cvs remove&nbsp;» sur ce fichier :
    </p>
<pre>
# <i>rm myoldfile.c</i>

<body>
    <p>
        La suppression du fichier est alors prévue par cvs et sera effective
        lors de votre prochain «&nbsp;commit&nbsp;». Une fois le 
        «&nbsp;commit&nbsp;» réalisé, 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.
    </p>
    <p>
        «&nbsp;cvs remove&nbsp;» est récursif, ce qui signifie que vous pouvez supprimer
        un ensemble de fichiers et lancer la commande «&nbsp;cvs remove&nbsp;» sans autre 
        argument depuis un répertoire parent. Ceci va marquer tous les fichiers supprimés
        comme «&nbsp;à supprimer&nbsp;» lors du prochain «&nbsp;commit&nbsp;».
    </p>
</body>
</section>

<body>
    <p>
        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
        «&nbsp;cvs remove&nbsp;» :
    </p>
<pre>
# <i>rm *.c</i>

<title>Supprimer un répertoire, suite</title>
<body>
    <p>
        Ensuite, faites un «&nbsp;commit&nbsp;» :
    </p>
<pre>
# cvs commit

# <i>rm -rf mydir</i>
</pre>
    <p>
        Remarquez que supprimer un répertoire ne nécessite pas un autre «&nbsp;commit&nbsp;». 
        L'ajout et la suppression de répertoires sur le dépôt distant se font en temps réel.
    </p>
</body>
</section>

    <p>
        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 :
    </p>
    <p>
        <ul>
            <li><uri>http://www.cvshome.org</uri> est la page principale du développement de CVS
                et offre beaucoup de documentation sur CVS, en particulier la
                <uri link="http://www.cvshome.org/docs/manual">documentation officielle en ligne de CVS</uri>.
            </li>
            <li>Le site <uri link="http://www.durak.org/cvswebsites/">CVS Version Control for Web Site Projects</uri>
                propose de bonnes informations sur comment utiliser CVS pour développer des sites Web.
            </li>
            <li>Karl Fogel a écrit un livre intitulé <uri link="http://cvsbook.red-bean.com/">Open Source Development with CVS</uri>.
                Certains chapitres de ce livre sont disponibles sur le site.
            </li>
            <li><uri link="http://www.freebsd.org/projects/cvsweb.html">cvsweb</uri> est un script
                CGI merveilleux qui fournit une interface web vers votre dépôt. Excellent pour le parcours rapide.
            </li>
            <li>Le site <uri link="http://www.loria.fr/~molli/cvs-index.html">CVS Bubbles</uri> 
                propose aussi de nombreuses informations dont «&nbsp;CVS FAQ-o-matic&nbsp;».
            </li>
        </ul>
    </p>

Return to bug 43324