Go to:
Gentoo Home
Documentation
Forums
Lists
Bugs
Planet
Store
Wiki
Get Gentoo!
Gentoo's Bugzilla – Attachment 26644 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]
cvs-tutorial.xml - Corrected translation for Tutoriel CVS Gentoo Linux
cvs-tutorial.xml (text/plain), 31.60 KB, created by
Olivier Fisette (RETIRED)
on 2004-02-29 21:29:16 UTC
(
hide
)
Description:
cvs-tutorial.xml - Corrected translation for Tutoriel CVS Gentoo Linux
Filename:
MIME Type:
Creator:
Olivier Fisette (RETIRED)
Created:
2004-02-29 21:29:16 UTC
Size:
31.60 KB
patch
obsolete
><?xml version='1.0' encoding="UTF-8"?> > ><!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> > ><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> > ><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 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 « 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=26644">View the attachment on a separate page</a>.</b>
View Attachment As Raw
Actions:
View
Attachments on
bug 43324
:
26623
|
26644
|
26651
