Go to:
Gentoo Home
Documentation
Forums
Lists
Bugs
Planet
Store
Wiki
Get Gentoo!
Gentoo's Bugzilla – Attachment 26651 Details for
Bug 43324
[fr] Corrections for cvs-tutorial.xml - Tutoriel CVS de Gentoo Linux
Home
|
New
–
[Ex]
|
Browse
|
Search
|
Privacy Policy
|
[?]
|
Reports
|
Requests
|
Help
|
New Account
|
Log In
[x]
|
Forgot Password
Login:
[x]
doc/fr/cvs-tutorial.xml
cvs-tutorial.xml (text/plain), 31.09 KB, created by
Xavier Neys (RETIRED)
on 2004-03-01 05:37:53 UTC
(
hide
)
Description:
doc/fr/cvs-tutorial.xml
Filename:
MIME Type:
Creator:
Xavier Neys (RETIRED)
Created:
2004-03-01 05:37:53 UTC
Size:
31.09 KB
patch
obsolete
><?xml version='1.0' encoding="UTF-8"?> ><!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> > ><!-- $Header: /home/cvsroot/gentoo/xml/htdocs/doc/fr/cvs-tutorial.xml,v 1.8 2004/03/01 13:04:58 neysx Exp $ --> > ><guide link="/doc/fr/cvs-tutorial.xml" lang="fr"> > ><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> > ><abstract> >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. ></abstract> > ><license/> > ><version>1.4</version> ><date>4 février 2004</date> > ><chapter> ><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 ; 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). ></p> ></body> ></section> > ><section> ><title>Qu'est ce que CVS et qu'est ce que ça fait ?</title> ><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 « 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. ></p> ></body> ></section> > ><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 >« 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. ></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> ></body> ></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> ></body> ></section> > > ><section> ><title>Installer CVS depuis les sources</title> ><body> ><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> ><pre> ># <i>tar xzvf cvs-1.11.tar.gz</i> ># <i>cd cvs-1.11</i> ># <i>./configure</i> ># <i>make</i> ># <i>make install</i> ></pre> ><p> >Maintenant, vous êtes prêt à travailler. ></p> ></body> ></section> ><section> ><title>Installer CVS avec un système de gestion de paquets</title> ><body> > ><p> >Beaucoup de distributions offrent une méthode facile pour installer des >logiciels. Par exemple, Gentoo offre la commande <c>emerge</c>. Pour installer >CVS, tapez simplement <c>emerge cvs</c> : ></p> > ><pre caption="Installer CVS avec emerge"> ># <i>emerge cvs</i> ></pre> > ></body> ></section> > > ><section> ><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> > ><section> ><title>Une racine CVS locale</title> ><body> ><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> > ><section> ><title>Une racine CVS pour un pserver distant (serveur avec mot de passe)</title> ><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 >« :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. ></p> ></body> ></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 à « 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. ></p> ></body> ></section> > ><section> ><title>Quelques précisions...</title> ><body> ><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 « 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. ></p> ></body> ></section> > ><section> ><title>Utiliser CVS, Partie 1</title> ><body> ><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 >« checkout » 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 : <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> > ><section> ><title>Uiliser CVS, partie 2</title> ><body> ><p> >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 : ></p> ><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/Manifest >U samba/README >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 « 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 »). ></p> ></body> ></section> > ><section> ><title>Fin du « checkout »</title> ><body> ><p> >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 ». ></p> ></body> ></section> > ><section> ><title>Mettre les sources à jour</title> ><body> ><p> >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. ></p> ><p> >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 : </p> ><pre> ># <i>cvs update -dP</i> ></pre> ></body> ></section> > ><section> ><title>« cvs update » en bref, partie 1</title> ><body> ><p> >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. ></p> ></body> ></section> > ><section> ><title>« cvs update » en bref, partie 2</title> ><body> ><p> >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). ></p> ><p> >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. ></p> ></body> ></section> ></chapter> ><chapter> ><title>CVS pour les developpeurs</title> > ><section> ><title>Modifier des fichiers</title> ><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 >« 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 : ></p> ><pre> ># <i>cvs update -dP</i> ></pre> ></body> ></section> > ><section> ><title>CVS fusionne les modifications des autres</title> ><body> ><p> >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. ></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 « commit » 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> > ><section> ><title>La fusion n'est pas parfaite</title> ><body> ><p> >Pourtant, si deux développeurs ou plus ont fait des modifications sur la ><i>même partie du même fichier</i>, 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. ></p> ></body> ></section> > > > ><section> ><title>Le « commit »</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 « 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 le « commit » de vos sources. Il suffit de taper la >commande suivante dans le répertoire principal de vos sources : ></p> ><pre> ># <i>cvs commit</i> ></pre> > > ></body> ></section> > ><section> ><title>Ce que fait le « commit »</title> ><body> ><p> >« cvs commit » 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 (« logs »)</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 « commit ». Pour accéder à ces informations, >faites : ></p> ><pre> ># <i>cvs log myfile.c</i> ></pre> ><p> >« 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 : ></p> ><pre> ># <i>cvs log | less</i> ></pre> > ></body> ></section> > ><section> ><title>Les options du « commit »</title> ><body> ><p> >Vous pourriez avoir envie d'utiliser un autre éditeur que celui que cvs utilise >par défaut lorsque vous faites un « cvs commit ». 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> ><pre> >export EDITOR=jpico ></pre> ><p> >Vous pouvez aussi spécifier le commentaire dans la ligne de commande de sorte >que cvs n'ait pas à ouvrir un éditeur de texte : ></p> ><pre> ># <i>cvs commit -m 'Ceci doit être un commentaire intelligent'</i> ></pre> ></body> ></section> > ><section> ><title>Le fichier .cvsrc</title> ><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 >diff -u -b -B >checkout -P >update -d -P ></pre> ></body> ></section> > ><section> ><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 « 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). ></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 « cvs commit ». 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 : ></p> ><pre> ># <i>mkdir foo</i> ># <i>cvs add foo</i> >Directory /home/cvsroot/mycode/foo added to the repository ></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 « commit » n'est pas requis. >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 ». ></p> ></body> ></section> > ><section> ><title>Remarques sur « cvs add »</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> ># <i>cvs add myfile.c</i> >cvs add: cannot open CVS/Entries for reading: No such file or directory >cvs [add aborted]: no repository ></pre> ></body> ></section> > ><section> ><title>Se familiariser avec « cvs update », partie 1</title> ><body> ><p> >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 : ></p> ><pre> ># <i>cvs update -dP</i> >? distfiles >? packages >? profiles ></pre> ></body> ></section> > ><section> ><title>Se familiariser avec « cvs update », partie 2</title> ><body> ><p> >« 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 : ></p> ><pre> >U [path] ></pre> ><p> >Utilisé lorsqu'un fichier est créé dans votre copie locale, ou si un fichier >que vous n'avez pas touché est mis à jour. ></p> ><pre> >A [path] ></pre> ><p> >L'ajout de ce fichier au dépôt a été programmé et sera officiellement ajouté >quand vous ferez un « cvs commit ». ></p> ></body> ></section> > > ><section> ><title>Se familiariser avec « cvs update », partie 3</title> ><body> ><pre> >R [path] ></pre> ><p> >à 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 un « cvs commit ». ></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 « C » indique que ce fichier présente des conflits et >nécessite une intervention manuelle avant de réaliser votre >« commit ». ></p> ></body> ></section> > ><section> ><title>Résoudre les conflits, introduction</title> ><body> ><p> >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. ></p> ></body> ></section> > ><section> ><title>Un exemple de conflit</title> ><body> ><p> >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 : ></p> ><pre> >date 25 Feb 2001 > >J'ai ajouté ce commentaire ></pre> ><p> >Imaginons qu'avant que je ne fasse un « commit » 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> >date 25 Feb 2001 > >Un autre développeur a ajouté ce commentaire ></pre> ></body> ></section> > ><section> ><title>Une exemple de conflit, suite</title> ><body> ><p> >Maintenant, lorsque je fais un « cvs update -dP » (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> >RCS file: /home/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 ></pre> ></body> ></section> > ><section> ><title>Résolution de conflit, partie 1</title> ><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 >« ChangeLog » : ></p> ><pre> ><<<<<<< ChangeLog >date 25 Feb 2001 > >J'ai ajouté ce commentaire > >======= >date 25 Feb 2001 > >Un autre développeur a ajouté ce commentaire > >>>>>>>> 1.363 ></pre> ></body> ></section> > ><section> ><title>Résolution de conflit, partie 2</title> ><body> ><p> >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 <i>devraient</i> 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 : ></p> ><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 « ======= » et autres marqueurs), je >peux faire un « commit » sans aucun problème. ></p> ></body> ></section> > ><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 >« commit » 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 ». ></p> ></body> ></section> > ><section> ><title>Supprimer un fichier</title> ><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 « cvs remove » sur ce fichier : ></p> ><pre> ># <i>rm myoldfile.c</i> ># <i>cvs remove myoldfile.c</i> ></pre> ></body> ></section> > ><section> ><title>Supprimer un fichier, suite</title> ><body> ><p> >La suppression du fichier est alors prévue par cvs et sera effective lors de >votre prochain « commit ». Une fois le « commit » 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> >« 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 du prochain >« commit ». ></p> ></body> ></section> > ><section> ><title>Supprimer un répertoire</title> ><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 >« cvs remove » : ></p> ><pre> ># <i>rm *.c</i> ># <i>cvs remove</i> ></pre> ></body> ></section> > ><section> ><title>Supprimer un répertoire, suite</title> ><body> ><p> >Ensuite, faites un « commit » : ></p> ><pre> ># cvs commit ></pre> ><p> >Et là , astuce : exécutez les commandes suivantes pour supprimer le >répertoire : ></p> ><pre> ># <i>cd ..</i> ># <i>cvs remove mydir</i> ># <i>rm -rf mydir</i> ></pre> ><p> >Remarquez que supprimer un répertoire ne nécessite pas un autre >« commit ». L'ajout et la suppression de répertoires sur le dépôt >distant se font en temps réel. ></p> ></body> ></section> > ><section> ><title>C'est terminé !</title> ><body> ><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 « CVS > FAQ-o-matic ». > </li> ></ul> ></p> ></body> ></section> > ><section> ><title>à propos de ce document</title> ><body> ><p> >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. ></p> ></body> ></section> > ></chapter> ></guide> >
<b>You cannot view the attachment while viewing its details because your browser does not support IFRAMEs. <a href="attachment.cgi?id=26651">View the attachment on a separate page</a>.</b>
View Attachment As Raw
Actions:
View
Attachments on
bug 43324
:
26623
|
26644
| 26651
