Commits

Romain Pelisse  committed f42151a Merge

Merge with William

  • Participants
  • Parent commits 320142c, 5abf0e1

Comments (0)

Files changed (2)

File fr/tour-basic.tex

 Vous pouvez utiliser n'importe quelle valeur pour votre \texttt{username},
 car cette information est destinée à d'autres personnes et non à être
 interprétée par Mercurial. La convention que la plupart des personnes
+<<<<<<< local
 suivent est d'utiliser leurs noms suivies de leurs adresses emails,
 comme montrée ci-dessus:
+=======
+suivent est d'utiliser leur nom suivi de leur adresse email,
+comme montrée ci dessus:
+>>>>>>> other
 
 \begin{note}
   Le mécanisme interne du serveur \textit{web} intégré à Mercurial,
   masque les adresses emails, pour rendre plus difficile leurs
   récupérations par les outils utilisés par les \textit{spammmers}.
-  Ceci réduit la probabilité que vous receviez encore plus de 
+  Ceci réduit la probabilité que de recevoir encore plus de 
   \textit{spam} si vous vous publiez un dépôt sur internet.
 \end{note}
 
 Lorsqu'on effectue une opération de \textit{commit}, Mercurial 
 lance automatiquement un éditeur de texte pour permettre de saisir
 un message qui décrira les modifications effectuées dans ce 
-\textit{changeset}. Ce message est nommée le \emph{message de 
+\textit{changeset}. Ce message est nommé le \emph{message de 
 \textit{commit}}. Ce sera un enregistrement pour tout lecteur 
 expliquant le pourquoi et le comment de vos modifications, et il sera
 affiché par la commande \hgcmd{log}.
   \emph{empty line}
   HG: changed hello.c
 \end{codesample2}
-Mercurial ignore les lignes qui commence avec ``\texttt{HG:}'', il 
+Mercurial ignore les lignes qui commencent avec ``\texttt{HG:}'', il 
 ne les utilise que pour nous indiquer quels fichiers modifiés il se 
 prépare à \textit{commiter}. Modifier ou effacer ces lignes n'a 
 aucune conséquence sur l'opération de \textit{commit}.
 
 Comme \hgcmd{log} n'affiche que la première ligne du message de
 \textit{commit} par défaut, il est souvent considéré comme une bonne
+<<<<<<< local
 pratique de rédiger des messages de \textit{commit} qui tiennent
+=======
+pratique de rédiger des messages de \textit{commit} qui n'entrent que 
+>>>>>>> other
 sur une seule ligne. Voilà un exemple concret de message de 
 \textit{commit} qui \emph{ne suit pas} cette directive, et qui a donc
 un résumé peu lisible.
 A ce sujet, il faut noter qu'il n'existe pas de règle absolue dans ce 
 domaine. Mercurial lui-même n'interprète pas les contenus des messages
 de \textit{commit}, ainsi votre projet est libre de concevoir différentes
+<<<<<<< local
 politiques de mise en page des messages.
+=======
+politiques de formatage des messages.
+>>>>>>> other
 
 Ma préférence personnelle va au message court, mais informatif, qui offre
-des précisions supplémentaires à ce que pourrait m'apprendre une commande
+des précisions supplémentaires par rapport à ce que pourrait m'apprendre une commande
 \hgcmdargs{log}{--patch}.
 
 \subsection{Annuler un \textit{commit}}
 
 Si, en rédigeant le message, vous décidez que finalement vous ne 
+<<<<<<< local
 voulez pas effectuer ce \textit{commit}, il suffit de simplement quitter
 l'éditeur sans sauvegarder. Ceci n'aura aucune conséquence sur le dépôt ou
+=======
+voulez pas effectuer ce \textit{commit}, il suffit de quitter simplement
+l'éditeur sans sauver. Ceci n'aura aucune conséquence sur le dépôt ou
+>>>>>>> other
 les fichiers de l'espace de travail.
 
+<<<<<<< local
 Si vous exécuter la commande \hgcmd{commit} sans aucun argument, elle
+=======
+Si vous exécutez la commande \hgcmd{commit} sans aucun argument, elle
+>>>>>>> other
 enregistre toutes les modifications que vous avez faites, comme le montre
-la commande \hgcmd{status} et \hgcmd{diff}.
+les commandes \hgcmd{status} et \hgcmd{diff}.
 
 \subsection{Admirer votre travail}
 
 identique à celle du \hgcmd{log}, mais qui n'affiche que la dernière
 révision du dépôt.
 \interaction{tour.tip}
+<<<<<<< local
 On fait couramment référence à la dernière révision du dépôt comme
+=======
+On fait couramment référénce à la dernière révision du dépôt comme
+>>>>>>> other
 étant la révision \textit{tip}, ou plus simplement le \textit{tip}.
 
 \section{Partager ses modifications}
 
 Pour commencer, construisons un clone de notre dépôt \dirname{hello} 
 qui ne contiendra pas le changement que nous venons d'effectuer. Nous
+<<<<<<< local
 l'appellerons notre dépôt temporaire \dirname{hello-pull}.
+=======
+appelerons notre dépôt temporaire \dirname{hello-pull}.
+>>>>>>> other
 \interaction{tour.clone-pull}
 
 Nous allons utiliser la commande \hgcmd{pull} pour apporter les 
 
 Nous avons jusqu'à maintenant grossièrement définie la relation 
 entre un dépôt et un espace de travail. La commande \hgcmd{pull} que
-nous avons exécuter dans la section~\ref{sec:tour:pull} a apportée
+nous avons exécutée dans la section~\ref{sec:tour:pull} a apporté
 des modifications, que nous avons vérifiées, dans notre dépôt, mais
 il n'y a aucune trace de ces modifications dans notre espace de travail.
 En effet, \hgcmd{pull} ne touche pas (par défaut) à l'espace de 
 travail. C'est la commande \hgcmd{update} qui s'en charge.
 \interaction{tour.update}
 
-Il peut sembler un peu étrange que la commande \hgcmd{pull} ne met
+Il peut sembler un peu étrange que la commande \hgcmd{pull} ne mette
 pas à jour l'espace de travail automatiquement. Il y a en fait une
+<<<<<<< local
 très bonne raison à cela : vous pouvez utilisez la commande 
+=======
+très bonne raison à cela: vous pouvez utiliser la commmande 
+>>>>>>> other
 \hgcmd{update} pour mettre à jour votre espace de travail à l'état
 dans lequel il était à \emph{n'importe quelle révision} de l'historique
 du dépôt. Si vous aviez un espace de travail contenant une ancienne
 
 Néanmoins, comme les opérations de \textit{pull} sont très souvent
 suivies d'un \textit{update}, Mercurial vous permet de combiner les
-deux aisément passant l'option \hgopt{pull}{-u} à la commande 
+deux aisément en passant l'option \hgopt{pull}{-u} à la commande
 \hgcmd{pull}
 \begin{codesample2}
   hg pull -u
 \end{codesample2}
 
 Si vous étudiez de nouveau la sortie de la commande \hgcmd{pull} dans
+<<<<<<< local
 la section~\ref{sec:tour:pull} quand nous l'avons exécuté sans l'option
 \hgopt{pull}{-u}, vous pouvez constater qu'elle a affiché le rappel assez
 utile comme quoi vous devez encore effectuer une opération pour mettre à jour
+=======
+la section~\ref{sec:tour:pull} quand nous l'avons exécutée sans l'option
+\hgopt{pull}{-u}, vous pouvez constater qu'elle a affiché un rappel assez
+utile : vous devez encore effectuer une opération pour mettre à jour
+>>>>>>> other
 votre espace de travail:
 \begin{codesample2}
   (run 'hg update' to get a working copy)
 \end{codesample2}
 
+<<<<<<< local
 Pour découvrir sur quelle révision de l'espace de travail on est, utilisez
+=======
+Pour découvrir quelle révision de l'espace de travail en est où, utiliser
+>>>>>>> other
 la commande \hgcmd{parents}. 
 \interaction{tour.parents}
 Si vous regardez de nouveau le dessin~\ref{fig:tour-basic:history}, vous
+<<<<<<< local
 verrez les flèches reliant entre eux les \textit{changeset}. Le nœud 
 d'où la flèche \emph{part} est dans chaque cas un parent, 
 et le nœud où la flèche \emph{arrive} est un enfant. 
+=======
+verrez que les flèches reliant les \textit{changeset} entre eux. Le noeud 
+dont la flèche mène \emph{de quelquepart} est dans chaque cas un parent, 
+et le node dont la flèche mène \emph{vers quelquepart} est un enfant. %%%TODO: vers quelque part ?
+>>>>>>> other
 L'espace de travail a un parent de la même manière, c'est ce \textit{changeset} 
 que l'espace de travail contient à ce moment.
+%%%TODO : difficile à comprendre : l'espace de travail a un parent, de la même manière, c'est ce changeset que l'espace...
 
 Pour mettre à jour l'espace de travail d'une révision particulière, 
 indiquez un numéro de révision ou un \textit{changeset~ID} à la commande 
 \interaction{tour.older}
 Si vous ne précisez pas de manière explicite de numéro de révision
 la commande \hgcmd{update} mettra à jour votre espace de travail avec
+<<<<<<< local
 le contenu de la révision \textit{tip}, comme montré dans l'exemple 
 ci-dessus lors du second appel à \hgcmd{update}.
+=======
+le contenu de la révsion \textit{tip}, comme montrée dans l'exemple 
+ci dessus lors du second appel à \hgcmd{update}.
+>>>>>>> other
 
 \subsection{Transférer les modifications à un autre dépôt}
 
 ``pousser'' tout simplement} nos modifications.
 \interaction{tour.clone-push}
 La commande \hgcmd{outgoing} nous indique quels changements nous
-allons transférer vers l'autre serveyr.
+allons transférer vers l'autre serveur ?
 \interaction{tour.outgoing}
 Et la commande \hgcmd{push} effectue réellement le transfert.
 \interaction{tour.push}
 
 \subsection{Partager ses modifications à travers le réseau}
 
+<<<<<<< local
 Les commandes que nous avons étudiés dans les sections précédentes
 ne se limitent pas aux dépôt locaux. Chacune commande fonctionne de la même
+=======
+Les commandes que nous avons étudiées dans les sections précédentes
+ne sont pas limitées aux dépôt locaux. Chacune fonctionne de la même
+>>>>>>> other
 manière à travers une connexion réseau, il suffit de lui passer une 
 URL à la place d'un chemin de fichier local.
 

File fr/tour-merge.tex

 \chapter{Un rapide tour de Mercurial: fusionner les travaux}
 \label{chap:tour-merge}
 
-Nous avons maintenons étudié comment clôner un dépôt, effectuer
+Nous avons maintenons étudié comment cloner un dépôt, effectuer
 des changements dedans, et récupérer ou transférer depuis un 
 autre dépôt. La prochaine étape est donc de \emph{fusionner} les
 modifications de différents dépôts.
 \section{Fusionner différents travaux} %%%TODO: better translation
 				       %%% for 'Merging streams of work' ?
 La fusion\footnote{NdT: Je garde fusion mais le jargon professionnel 
-employera généralement le terme \textit{merge}.} est un aspect 
+emploiera généralement le terme \textit{merge}.} est un aspect 
 fondamental lorsqu'on travail avec un gestionnaire de source 
-distribé.
+distribué.
 \begin{itemize}
 \item Alice et Bob ont chacun une copie personnelle du dépôt d'un
   projet sur lequel ils collaborent. Alice corrige un \textit{bug} 
 \end{itemize}
 
 Parce que la fusion est une opération si commune que je dois réaliser,
-Mercurial la rend facile. Etudions ensemble le déroulement des opérations.
-Nous commencerons par faire un clone d'encore un autre dépôt (vous voyez
+Mercurial la rend facile. Étudions ensemble le déroulement des opérations.
+Nous commencerons par faire un clone de encore un autre dépôt (vous voyez
 comment on fait ça tout le temps ?) puis nous ferons quelques modifications
 dessus.
 \interaction{tour.merge.clone}
 
 \interaction{tour.merge.pull}
 
-Néanmoins, la commande \hgcmd{pull} nous indique quelquechose au 
+Néanmoins, la commande \hgcmd{pull} nous indique quelque chose au 
 sujet des ``heads''.
 
 \subsection{\textit{Head changesets}} %%%TODO: Hard (too?) to translate
 \end{figure}
 
 Ceci met à jour de l'espace de travail de manière à ce qu'il contienne
-les modifications des \emph{deux} \textit{heads}, ce qui apparait dans
+les modifications des \emph{deux} \textit{heads}, ce qui apparaît dans
 les sorties de la commande \hgcmd{parents} et le contenu de 
 \filename{hello.c}. 
 \interaction{tour.merge.parents}
 
-\subsection{Committing the results of the merge}
+\subsection{Effectuer le \textit{commit} du résultat de la fusion}
 
-Whenever we've done a merge, \hgcmd{parents} will display two parents
-until we \hgcmd{commit} the results of the merge.
+Dès l'instant où vous avez effectuer une fusion, \hgcmd{parents} vous
+affichera deux parents, avant que vous n'exécuter la commande 
+\hgcmd{commit} sur le résultat de la fusion.
 \interaction{tour.merge.commit}
 Nous avons maintenant un nouveau \textit{tip}, remarquer qu'il contient
 \emph{à la fois} nos anciennes \textit{heads} et leurs parents. Ce sont
 \section{Fusionner les modifications en conflit}
 
 La plupart des fusions sont assez simple à réaliser, mais parfois 
-vous vous trouverez à fusioner des fichiers où la modification touche
+vous vous trouverez à fusionner des fichiers où la modification touche
 la même portion de code, au sein d'un même fichier. À moins que ces
 modification ne soient identiques, ceci aboutira à un \emph{conflit},
-et vous devrez décider comment réconcillier les différentes modifications
+et vous devrez décider comment réconcilier les différentes modifications
 dans un tout cohérent. 
 
 \begin{figure}[ht]
 du conflit est de décider à quoi le fichier devrait ressembler.
 
 Mercurial n'a pas de mécanisme interne pour gérer les conflits. 
-À la place, il exéctue un programme externe appelé \command{hgmerge}.
+À la place, il exécute un programme externe appelé \command{hgmerge}.
 Il s'agit d'un script shell qui est embarqué par Mercurial, vous
 pouvez le modifier si vous le voulez. Ce qu'il fait par défaut est
 d'essayer de trouver un des différents outils de fusion qui seront
 
 Il est aussi possible de demander à Mercurial d'exécuter un autre
 programme ou un autre script au lieu de la commande \command{hgmerge},
-en définissant la variable d'environement \envar{HGMERGE} avec le nom
+en définissant la variable d'environnement \envar{HGMERGE} avec le nom
 du programme de votre choix.
 
 \subsection{Utiliser un outil graphique de fusion}
 qui indiquent des conflits non résolus, avec un fusion manuel et pertinente
 de ``notre'' version et de la ``leur''. 
 
-Tout les quatres panneaux sont \emph{accrochés ensemble}, si nous déroulons
+Tout les quatre panneaux sont \emph{accrochés ensemble}, si nous déroulons
 les ascenseurs verticalement ou horizontalement dans chacun d'entre eux, les
 autres sont mise à jours avec la section correspondantes dans leurs fichiers.
 
 \end{figure}
 
 Pour chaque portion de fichier posant problème, nous pouvons choisir 
-de résoudre le le conlfit en utilisant en utilisant une combinaison 
+de résoudre le le conflit en utilisant en utilisant une combinaison 
 de texte depuis la version de base, la notre, ou la leur. Nous pouvons 
 aussi éditer manuellement les fichiers à tous moments, si c'est
 nécessaire.
 
 Il y a \emph{beaucoup} d'outils de fusion disponibles, bien trop pour
-en parler de tous ici. Leurs disponibilités varient selon les plateformes
-ainsi que leurs avantages et incovénients. La plupart sont optimisé pour
+en parler de tous ici. Leurs disponibilités varient selon les plate formes
+ainsi que leurs avantages et inconvénients. La plupart sont optimisé pour
 la fusion de fichier contenant un texte plat, certains sont spécialisé
-dans un format de fichier précis (générallement XML).
+dans un format de fichier précis (généralement XML).
 
-\subsection{A worked example}
+\subsection{A worked example} %TODO: Find a translation for this !
 
-In this example, we will reproduce the file modification history of
-figure~\ref{fig:tour-merge:conflict} above.  Let's begin by creating a
-repository with a base version of our document.
+Dans cet exemple, nous allons reproduire la modification de l'historique
+du fichier de la figure~\ref{fig:tour-merge:conflict} ci dessus. Commençons
+par créer un dépôt avec une version de base de notre document.
+
 \interaction{tour-merge-conflict.wife}
-We'll clone the repository and make a change to the file.
+Créons un clone de ce dépôt et faisons une modification dans le fichier.
 \interaction{tour-merge-conflict.cousin}
-And another clone, to simulate someone else making a change to the
-file.  (This hints at the idea that it's not all that unusual to merge
-with yourself when you isolate tasks in separate repositories, and
-indeed to find and resolve conflicts while doing so.)
+Et un autre clone, pour simuler que quelqu'un d'autre effectuer une
+modification sur le fichier. (Ceci pour suggérer qu'il n'est pas rare
+de devoir effectuer des \textit{merge} avec vos propres travaux quand 
+vous isoler les tâches dans des dépôts distincts. En effet, vous 
+aurez alors à trouver et résoudre certains conflits).
 \interaction{tour-merge-conflict.son}
-Having created two different versions of the file, we'll set up an
-environment suitable for running our merge.
+Maintenant que ces deux versions différentes du même fichier sont 
+créées, nous allons configurer l'environnement approprié pour exécuter 
+notre \textit{merge}.
 \interaction{tour-merge-conflict.pull}
 
-In this example, I won't use Mercurial's normal \command{hgmerge}
-program to do the merge, because it would drop my nice automated
-example-running tool into a graphical user interface.  Instead, I'll
-set \envar{HGMERGE} to tell Mercurial to use the non-interactive
-\command{merge} command.  This is bundled with many Unix-like systems.
-If you're following this example on your computer, don't bother
-setting \envar{HGMERGE}.
+Dans cette exemple, je n'utiliserais pas la commande Mercurial
+habituelle \command{hgmerge} pour effectuer le \textit{merge},
+car il me faudrait abandonner ce joli petit exemple automatisé
+pour utiliser un outil graphique. À la place, je vais définir
+la variable d'environnement \envar{HGMERGE} pour indiquer à 
+Mercurial d'utiliser la commande non-interactive \command{merge}.
+Cette dernière est embarqué par de nombreux systèmes ``à la Unix''.
+Si vous exécuter cet exemple depuis votre ordinateur, ne vous
+occupez pas de définir \envar{HGMERGE}.
 \interaction{tour-merge-conflict.merge}
-Because \command{merge} can't resolve the conflicting changes, it
-leaves \emph{merge markers} inside the file that has conflicts,
-indicating which lines have conflicts, and whether they came from our
-version of the file or theirs.
+Parce que \command{merge} ne peut pas résoudre les modifications
+conflictuelles, il laisse des \emph{marqueurs de différences}
+\footnote{NdT: Oui, je traduis \textit{merge markers} par un sens
+inverse en Français, mais je pense vraiment que c'est plus clair 
+comme ça...} à l'intérieur du fichier qui a des conflits, indiquant
+clairement quelles lignes sont en conflits, et si elles viennent de
+notre fichier ou du fichier externe.
 
-Mercurial can tell from the way \command{merge} exits that it wasn't
-able to merge successfully, so it tells us what commands we'll need to
-run if we want to redo the merging operation.  This could be useful
-if, for example, we were running a graphical merge tool and quit
-because we were confused or realised we had made a mistake.
+Mercurial peut distinguer, à la manière dont la commande \command{merge}
+se termine, qu'elle n'a pas été capable d'effectuer le \textit{merge},
+alors il nous indique qu'il faut devons effectuer de nouveau cette
+opération. Ceci peut être très utile si, par exemple, nous exécutons un
+outil graphique de fusion et que nous le quittons sans se rendre compte
+qu'il reste des conflits ou simplement par erreur.
 
-If automatic or manual merges fail, there's nothing to prevent us from
-``fixing up'' the affected files ourselves, and committing the results
-of our merge:
+Si le \textit{merge} automatique ou manuel échoue, il n'y a rien pour
+nous empêcher de ``corriger le tir'' en modifiant nous même les fichiers,
+et enfin effectuer le \textit{commit} du fichier:
 \interaction{tour-merge-conflict.commit}
 
 \section{Simplifying the pull-merge-commit sequence}