Second part of prior commit

1 files changed, 129 insertions, 0 deletions

diff --git a/tde-i18n-fr/docs/tdevelop/tdevelop/cvs.docbook b/tde-i18n-fr/docs/tdevelop/tdevelop/cvs.docbook
new file mode 100644
index 00000000000..8b59d76b2b5
--- /dev/null
+++ b/tde-i18n-fr/docs/tdevelop/tdevelop/cvs.docbook
@@ -0,0 +1,129 @@
+<chapter id="cvs">
+<title
+>Utilisation de &CVS;</title>
+<indexterm zone="cvs"
+><primary
+>CVS</primary
+></indexterm>
+<indexterm zone="cvs"
+><primary
+>contrôle de révision</primary
+></indexterm>
+
+<sect1 id="cvs-basics">
+<title
+>Bases de &CVS;</title>
+
+<para
+>&CVS; est le système de contrôle de révision auquel beaucoup de projets « open source » - dont &kde; &mdash; font appel. Il stocke tous les codes sources dans un emplacement central, appelé le <emphasis
+>référentiel</emphasis
+>. À partir du référentiel, les développeurs peuvent extraire une version actuelle du projet ou des instantanés de celui-ci à des moments arbitraires. Contrairement à certains autres systèmes de contrôle de révision, il n'est pas nécessaire de <emphasis
+>verrouiller</emphasis
+> les fichiers sur lesquels on veut travailler. Ainsi, le développement peut être extrêmement parallélisé. </para>
+
+<para
+>Chaque fois qu'un développeur a terminé une tâche, il <emphasis
+>valide</emphasis
+> (« commits ») son code (accompagné d'un message de journal). &CVS; prend les travaux pour fusionner les changements effectués par plusieurs développeurs. Il peut naturellement arriver que des développeurs travaillent sur le même morceau de code, ce qui a pour conséquence un ensemble conflictuel de changements (en pratique, cela se produit rarement et c'est souvent le signe d'un manque de communication). Dans ce cas, &CVS; rejette une validation. Un fichier peut être validé uniquement après que tous les conflits ont été résolus. </para>
+
+<para
+>Jusqu'ici, ce document s'est borné à une description des fonctionnalités de base de &CVS; qu'on est susceptible de rencontrer. Cependant, &CVS; a beaucoup plus de cordes à son arc : on peut maintenir plusieurs branches d'un projet (&pex; &kde; 1.1.2 et &kde; 2 étaient des branches de l'arborescence de développement de &kde;), fusionner des changements d'une branche à une autre, demander des différences entre révisions, l'historique de révision des fichiers, &etc; </para>
+
+<para
+>&CVS; est implémenté sous la forme d'un système client-serveur. En tant qu'utilisateur, toute la communication avec le référentiel passe par le programme en ligne de commande &cvs;. Une interface utilisateur de niveau plus élevé est disponible grâce à des interfaces comme &cervisia; (<ulink url="http://cervisia.sf.net"
+></ulink
+>) ou <application
+>TkCVS</application
+> (<ulink url="http://tkcvs.sf.net"
+></ulink
+>). Dans &tdevelop;, seule une petite partie de la fonctionnalité de &cvs; qui est importante pour votre travail quotidien peut être utilisée directement. </para>
+
+<para
+>Une bonne connaissance de base de l'utilisation de &CVS; est supposée. En particulier, vous devrez savoir comment extraire un projet donné du référentiel. Nous recommandons l'ouvrage « Open Source Development With &CVS; », par Karl Fogel, qui est distribué librement (sauf en ce qui concerne les chapitres non techniques). Consultez <ulink url="http://cvsbook.red-bean.com/cvsbook.html"
+></ulink
+>. </para>
+
+</sect1
+> <!-- cvs-basics -->
+
+<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+<sect1 id="cvs-commands">
+<title
+>Commandes &CVS; dans &tdevelop;</title>
+
+<para
+>Dans les vues des fichiers, les éléments de menu contextuel suivants sont disponibles : </para>
+
+<variablelist>
+<varlistentry>
+<term
+>Ajouter au référentiel</term>
+<listitem>
+<para
+>Prépare le fichier marqué pour son ajout au référentiel. Le fichier sera transféré au référentiel la prochaine fois que vous le validerez (ou le dossier qui le contient). </para>
+</listitem>
+</varlistentry>
+
+<varlistentry>
+<term
+>Supprimer du référentiel</term>
+<listitem>
+<para
+>Prépare un fichier pour sa suppression du référentiel. Comme cette action supprime aussi le fichier sur le système de fichier local, soyez prudent en utilisant cette fonctionnalité ! </para>
+</listitem>
+</varlistentry>
+
+<varlistentry>
+<term
+>Mettre à jour</term>
+<listitem>
+<para
+>Exécute <command
+>cvs update</command
+> pour fusionner tout changement d'autres utilisateurs dans votre dossier de travail. Quand vous employez cet élément de menu sur un dossier, la mise à jour s'effectue récursivement, sauf si vous avez désactivé cette fonction dans le fichier de configuration <filename
+>.cvsrc</filename
+>. </para>
+</listitem>
+</varlistentry>
+
+<varlistentry>
+<term
+>Valider</term>
+<listitem>
+<para
+>Exécute <command
+>cvs commit</command
+> pour envoyer tout changement effectué localement sur le référentiel. Notez que vous devriez faire une mise à jour auparavant. Sinon, si un autre utilisateur a validé ses propres changements avant, &CVS; risque de vous retourner un message d'erreur. </para>
+</listitem>
+</varlistentry>
+</variablelist>
+
+<para
+>Toutes ces commandes sont invoquées en tant que sous-processus par &tdevelop;, sans autres options sur la ligne de commande ou variables d'environnement variables. Ce peut être un problème quand la connexion avec le serveur &CVS; passe par une connexion &ssh; et nécessite que vous saisissiez un mot de passe chaque fois que vous validez ou mettez à jour. C'est par exemple nécessaire quand votre projet est hébergé sur <filename
+>sourceforge.net</filename
+>. La FAQ de &CVS;/SSH que vous pouvez trouver dans la documentation de SourceForge décrit quelques contournements pour ce problème. </para>
+
+</sect1
+> <!-- cvs-basics -->
+
+<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+<sect1 id="cvs-behind">
+<title
+>Les coulisses</title>
+
+<sect2 id="cvs-behind-workdir">
+<title
+>Ce que &CVS; enregistre dans le dossier de travail</title>
+
+<para
+>(... à écrire ...) </para>
+</sect2
+> <!-- cvs-behind-workdir -->
+
+</sect1
+> <!-- cvs-behind -->
+
+</chapter
+> <!-- cvs -->