hgbook
changeset 951:de3b3aaaa159
Finished works on tour-basic... Still need reviewing, especially the last 200 lines
author | Romain PELISSE <belaran@gmail.com> |
---|---|
date | Tue Feb 17 23:08:16 2009 +0100 (2009-02-17) |
parents | f6874ae04dde |
children | f2cd9743c473 |
files | fr/tour-basic.tex |
line diff
1.1 --- a/fr/tour-basic.tex Tue Feb 17 18:53:33 2009 +0100 1.2 +++ b/fr/tour-basic.tex Tue Feb 17 23:08:16 2009 +0100 1.3 @@ -426,8 +426,7 @@ 1.4 celle ci sera utilisée ensuite. 1.5 \item Enfin, Mercurial interrogera votre système pour trouver votre 1.6 nom d'utilisateur local ainsi que le nom de la machine hôte, et il 1.7 -%%%FIXME : et il quoi ? un nom... 1.8 - un nom d'utilisateur à partir de ces composants. Comme il arrive 1.9 + fabriquera un nom d'utilisateur à partir de ces données. Comme il arrive 1.10 souvent que ce genre de noms soit totalement inutile, il vous 1.11 préviendra en affichant un message d'avertissement. 1.12 \end{enumerate} 1.13 @@ -460,51 +459,56 @@ 1.14 définir la valeur de l'élément \texttt{username} dans la section 1.15 \texttt{ui}''. Une section continue jusqu'à ce qu'une nouvelle 1.16 commence, ou que la fin du fichier soit atteinte. Mercurial ignore 1.17 -les lignes vide et traite tout texte 1.18 -file. Mercurial ignores empty lines and treats any text from 1.19 -``\texttt{\#}'' to the end of a line as a comment. 1.20 - 1.21 -\subsubsection{Choosing a user name} 1.22 - 1.23 -You can use any text you like as the value of the \texttt{username} 1.24 -config item, since this information is for reading by other people, 1.25 -but for interpreting by Mercurial. The convention that most people 1.26 -follow is to use their name and email address, as in the example 1.27 -above. 1.28 +les lignes vide et traite tout texte situé à la suite d'un 1.29 +``\texttt{\#}'' jusqu'à la fin de la ligne comme un commentaire. 1.30 + 1.31 +\subsubsection{Choisir un nom d'utilisateur} 1.32 + 1.33 +Vous pouvez utiliser n'importe quelle valeur pour votre \texttt{username}, 1.34 +car cette information est destinée à d'autres personnes et non à être 1.35 +interprétée par Mercurial. La convention que la plupart des personnes 1.36 +suivent est d'utiliser leurs noms suivies de leurs adresses emails, 1.37 +comme montrée ci dessus: 1.38 1.39 \begin{note} 1.40 - Mercurial's built-in web server obfuscates email addresses, to make 1.41 - it more difficult for the email harvesting tools that spammers use. 1.42 - This reduces the likelihood that you'll start receiving more junk 1.43 - email if you publish a Mercurial repository on the web. 1.44 + Le mécanisme interne du serveur \textit{web} intégré à Mercurial, 1.45 + masque les adresses emails, pour rendre plus difficile leurs 1.46 + récupérations par les outils utilisés par les \textit{spammmers}. 1.47 + Ceci réduit la probabilité que vous receviez encore plus de 1.48 + \textit{spam} si vous vous publiez un dépôt sur internet. 1.49 \end{note} 1.50 1.51 -\subsection{Writing a commit message} 1.52 - 1.53 -When we commit a change, Mercurial drops us into a text editor, to 1.54 -enter a message that will describe the modifications we've made in 1.55 -this changeset. This is called the \emph{commit message}. It will be 1.56 -a record for readers of what we did and why, and it will be printed by 1.57 -\hgcmd{log} after we've finished committing. 1.58 +\subsection{Rédiger un message de \textit{commit}} 1.59 + 1.60 +Lorsque l'on effectue une opération de \textit{commit}, Mercurial 1.61 +lance automatiquement un éditeur de texte pour permettre de saisir 1.62 +un message qui décrira les modifications effectuées dans ce 1.63 +\textit{changeset}. Ce message est nommée le \emph{message de 1.64 +\textit{commit}}. Ce sera un enregistrement pour tout lecteur 1.65 +expliquant le pourquoi et le comment de vos modifications, et il sera 1.66 +affiché par la commande \hgcmd{log}. 1.67 \interaction{tour.commit} 1.68 1.69 -The editor that the \hgcmd{commit} command drops us into will contain 1.70 -an empty line, followed by a number of lines starting with 1.71 -``\texttt{HG:}''. 1.72 +L'éditor que la commande \hgcmd{commit} déclenche ne contiendra 1.73 +qu'une ligne vide suivi d'un certain nombre de lignes commençant 1.74 +par ``\texttt{HG:}''. 1.75 \begin{codesample2} 1.76 \emph{empty line} 1.77 HG: changed hello.c 1.78 \end{codesample2} 1.79 -Mercurial ignores the lines that start with ``\texttt{HG:}''; it uses 1.80 -them only to tell us which files it's recording changes to. Modifying 1.81 -or deleting these lines has no effect. 1.82 - 1.83 -\subsection{Writing a good commit message} 1.84 - 1.85 -Since \hgcmd{log} only prints the first line of a commit message by 1.86 -default, it's best to write a commit message whose first line stands 1.87 -alone. Here's a real example of a commit message that \emph{doesn't} 1.88 -follow this guideline, and hence has a summary that is not readable. 1.89 +Mercurial ignore les lignes qui commence avec ``\texttt{HG:}'', il 1.90 +ne les utilise que pour nous indiquer quels fichiers modifiés il se 1.91 +prépare à \textit{commiter}. Modifier ou effacer ces lignes n'a 1.92 +aucune conséquence sur l'opération de \textit{commit}. 1.93 + 1.94 +\subsection{Rédiger un message de \textit{approprié}} 1.95 + 1.96 +Comme \hgcmd{log} n'affiche que la première ligne du message de 1.97 +\textit{commit} par défaut, il est souvent considéré comme une bonne 1.98 +pratique de rédiger des messages de \textit{commit} qui rentre que 1.99 +sur une seule ligne. Voilà un exemple concret de message de 1.100 +\textit{commit} qui \emph{ne suit pas} cette directive, et qui a donc 1.101 +un résumé peu lisible. 1.102 \begin{codesample2} 1.103 changeset: 73:584af0e231be 1.104 user: Censored Person <censored.person@example.org> 1.105 @@ -512,153 +516,171 @@ 1.106 summary: include buildmeister/commondefs. Add an exports and install 1.107 \end{codesample2} 1.108 1.109 -As far as the remainder of the contents of the commit message are 1.110 -concerned, there are no hard-and-fast rules. Mercurial itself doesn't 1.111 -interpret or care about the contents of the commit message, though 1.112 -your project may have policies that dictate a certain kind of 1.113 -formatting. 1.114 - 1.115 -My personal preference is for short, but informative, commit messages 1.116 -that tell me something that I can't figure out with a quick glance at 1.117 -the output of \hgcmdargs{log}{--patch}. 1.118 - 1.119 -\subsection{Aborting a commit} 1.120 - 1.121 -If you decide that you don't want to commit while in the middle of 1.122 -editing a commit message, simply exit from your editor without saving 1.123 -the file that it's editing. This will cause nothing to happen to 1.124 -either the repository or the working directory. 1.125 - 1.126 -If we run the \hgcmd{commit} command without any arguments, it records 1.127 -all of the changes we've made, as reported by \hgcmd{status} and 1.128 -\hgcmd{diff}. 1.129 - 1.130 -\subsection{Admiring our new handiwork} 1.131 - 1.132 -Once we've finished the commit, we can use the \hgcmd{tip} command to 1.133 -display the changeset we just created. This command produces output 1.134 -that is identical to \hgcmd{log}, but it only displays the newest 1.135 -revision in the repository. 1.136 +A ce sujet, il faut noter qu'il n'existe pas de règle absolu dans ce 1.137 +domaine. Mercurial lui-même n'interprète pas les contenus des messages 1.138 +de \textit{commit}, ainsi votre projet est libre de concevoir différentes 1.139 +politiques de formattage des messages. 1.140 + 1.141 +Ma préférence personnelle va au message court, mais informatif, qui offre 1.142 +des précisions supplémentaires à ce que pourrait m'apprendre une commande 1.143 +\hgcmdargs{log}{--patch}. 1.144 + 1.145 +\subsection{Annuler un \textit{commit}} 1.146 + 1.147 +Si, en rédigeant le message, vous décidez que finalement vous ne 1.148 +voulez pas effectuer ce \textit{commit}, il suffit de simplement quitter 1.149 +l'éditeur sans sauver. Ceci n'aura aucune conséquence sur le dépôt ou 1.150 +les fichiers de l'espace de travail. 1.151 + 1.152 +Si vous exécuter la commande \hgcmd{commit} sans aucun arguments, elle 1.153 +enregistre toutes les modifications que vous avez faites, comme le montre 1.154 +la commande \hgcmd{status} et \hgcmd{diff}. 1.155 + 1.156 +\subsection{Admirer votre travail} 1.157 + 1.158 +Une fois que votre \textit{commit} est terminé, vous pouvez utiliser 1.159 +la commande \hgcmd{tip} pour afficher le \textit{changeset} que nous 1.160 +venons de créer. Cette commande produit une sortie à l'écran qui est 1.161 +identique à celle du \hgcmd{log}, maios qui n'affiche que la dernière 1.162 +révision du dépôt. 1.163 \interaction{tour.tip} 1.164 -We refer to the newest revision in the repository as the tip revision, 1.165 -or simply the tip. 1.166 - 1.167 -\section{Sharing changes} 1.168 - 1.169 -We mentioned earlier that repositories in Mercurial are 1.170 -self-contained. This means that the changeset we just created exists 1.171 -only in our \dirname{my-hello} repository. Let's look at a few ways 1.172 -that we can propagate this change into other repositories. 1.173 - 1.174 -\subsection{Pulling changes from another repository} 1.175 +On fait courament référénce à la dernière révision du dépôt comme 1.176 +étant la révision \textit{tip}, ou plus simplement le \textit{tip}. 1.177 + 1.178 +\section{Partager ses modifications} 1.179 + 1.180 +Nous avons mentionné plus haut que les dépôts de Mercurial 1.181 +sont autosuffisants. Ce qui signifie que le \textit{changeset} 1.182 +que vous venez de créer existe seulement dans votre répertoire 1.183 +\dirname{my-hello}. Etudions comment propager cette modification 1.184 +dans d'autres dépôts. 1.185 + 1.186 +\subsection{Récupérer les modifications d'autres dépôts} 1.187 \label{sec:tour:pull} 1.188 1.189 -To get started, let's clone our original \dirname{hello} repository, 1.190 -which does not contain the change we just committed. We'll call our 1.191 -temporary repository \dirname{hello-pull}. 1.192 +Pour commencer, construisons un clône de notre dépôt \dirname{hello} 1.193 +qui ne contiendra pas le changement que nous venons d'effectuer. Nous 1.194 +l'appelerons notre dépôt temporaire \dirname{hello-pull}. 1.195 \interaction{tour.clone-pull} 1.196 1.197 -We'll use the \hgcmd{pull} command to bring changes from 1.198 -\dirname{my-hello} into \dirname{hello-pull}. However, blindly 1.199 -pulling unknown changes into a repository is a somewhat scary 1.200 -prospect. Mercurial provides the \hgcmd{incoming} command to tell us 1.201 -what changes the \hgcmd{pull} command \emph{would} pull into the 1.202 -repository, without actually pulling the changes in. 1.203 +Nous allons utiliser la commande \hgcmd{pull} pour apporter les 1.204 +modifications depuis \dirname{my-hello} dans \dirname{hello-pull}. 1.205 +Néanmoins, récupérer aveuglement des modifications depuis un dépôt 1.206 +a quelquechose d'un peu effrayant. Mercurial propose donc une 1.207 +commande \hgcmd{incoming} qui permet de savoir quelles modifications 1.208 +la commande \hgcmd{pull} \emph{pourrait} entraîner dans notre dépôt, 1.209 +et ceci sans effectuant réellement de modification dessus. 1.210 \interaction{tour.incoming} 1.211 -(Of course, someone could cause more changesets to appear in the 1.212 -repository that we ran \hgcmd{incoming} in, before we get a chance to 1.213 -\hgcmd{pull} the changes, so that we could end up pulling changes that we 1.214 -didn't expect.) 1.215 - 1.216 -Bringing changes into a repository is a simple matter of running the 1.217 -\hgcmd{pull} command, and telling it which repository to pull from. 1.218 +(Bien évidement, quelqu'un pourrait peut ajouter des modifications 1.219 +supplémentaires sur le dépôt que nous étudions avec \hgcmd{incoming}, 1.220 +avant que nous ayons effectué notre \hgcmd{pull}, avec comme 1.221 +triste conséquence que nous aurons récupéré des modifications que 1.222 +nous n'attendions pas.) 1.223 + 1.224 +Apporter les modifications rapatriées dans un dépôt sera résume donc 1.225 +à exécuter la commande \hgcmd{pull}, et préciser depuis quel dépôt 1.226 +effectuer le \hgcmd{pull}. 1.227 \interaction{tour.pull} 1.228 -As you can see from the before-and-after output of \hgcmd{tip}, we 1.229 -have successfully pulled changes into our repository. There remains 1.230 -one step before we can see these changes in the working directory. 1.231 - 1.232 -\subsection{Updating the working directory} 1.233 - 1.234 -We have so far glossed over the relationship between a repository and 1.235 -its working directory. The \hgcmd{pull} command that we ran in 1.236 -section~\ref{sec:tour:pull} brought changes into the repository, but 1.237 -if we check, there's no sign of those changes in the working 1.238 -directory. This is because \hgcmd{pull} does not (by default) touch 1.239 -the working directory. Instead, we use the \hgcmd{update} command to 1.240 -do this. 1.241 + 1.242 +Comme vous le voyez avec une sortie avant et après de la commande 1.243 +\hgcmd{tip}, nous avons réussi à récupérer aisément les modifications 1.244 +dans notre dépôt. Il reste néanmoins quelquechose à faire avant de 1.245 +placer ces modifications dans l'espace de travail. 1.246 + 1.247 +\subsection{Mise à jour de l'espace de travail} 1.248 + 1.249 +Nous avons jusqu'à maintenant que grossièrement définie la relation 1.250 +entre un dépôt et un espace de travail. La commande \hgcmd{pull} que 1.251 +nous avons exécuter dans la section~\ref{sec:tour:pull} a apportée 1.252 +des modifications, que nous avons vérifiées, dans notre dépôt, mais 1.253 +il n'ya aucune trace de ces modifications dans notre espace de travail. 1.254 +En effet, \hgcmd{pull} ne touche pas (par défaut) à l'espace de 1.255 +travail. C'est la commande \hgcmd{update} qui s'en charge. 1.256 \interaction{tour.update} 1.257 1.258 -It might seem a bit strange that \hgcmd{pull} doesn't update the 1.259 -working directory automatically. There's actually a good reason for 1.260 -this: you can use \hgcmd{update} to update the working directory to 1.261 -the state it was in at \emph{any revision} in the history of the 1.262 -repository. If you had the working directory updated to an old 1.263 -revision---to hunt down the origin of a bug, say---and ran a 1.264 -\hgcmd{pull} which automatically updated the working directory to a 1.265 -new revision, you might not be terribly happy. 1.266 - 1.267 -However, since pull-then-update is such a common thing to do, 1.268 -Mercurial lets you combine the two by passing the \hgopt{pull}{-u} 1.269 -option to \hgcmd{pull}. 1.270 +Il peut sembler un peu étrange que la commande \hgcmd{pull} ne met 1.271 +pas à jour l'espace de travail automatiquement. Il y a en fait une 1.272 +très bonne raison à cela: vous pouvez utilisez la commmande 1.273 +\hgcmd{update} pour mettre à jour votre espace de travail à l'état 1.274 +dans lequel il était à \emph{n'importe quelle révision} de l'historique 1.275 +du dépôt. Si vous aviez un espace de travail contenant une ancienne 1.276 +révision---pour chercher l'origine d'un \textit{bug}, par exemple---et 1.277 +que vous effectuiez un \hgcmd{pull} qui mettrait à jour automatiquement 1.278 +votre espace de travail, vous ne seriez probablement pas très satisfait. 1.279 + 1.280 +Néanmoins, commme les opérations de \textit{pull} sont très souvent 1.281 +suivies d'un \textit{update}, Mercurial vous permet de combiner les 1.282 +deux aisément passant l'option \hgopt{pull}{-u} à la commande 1.283 +\hgcmd{pull} 1.284 \begin{codesample2} 1.285 hg pull -u 1.286 \end{codesample2} 1.287 -If you look back at the output of \hgcmd{pull} in 1.288 -section~\ref{sec:tour:pull} when we ran it without \hgopt{pull}{-u}, 1.289 -you can see that it printed a helpful reminder that we'd have to take 1.290 -an explicit step to update the working directory: 1.291 + 1.292 +Si vous étudiez de nouveau la sortie de la commande \hgcmd{pull} dans 1.293 +la section~\ref{sec:tour:pull} quand nous l'avons exécuter sans l'option 1.294 +\hgopt{pull}{-u}, vous pouvez constater qu'elle a afficher un rappel assez 1.295 +utile que vous devez encore effectuer une opération pour mettre à jour 1.296 +votre espace de travail: 1.297 \begin{codesample2} 1.298 (run 'hg update' to get a working copy) 1.299 \end{codesample2} 1.300 1.301 -To find out what revision the working directory is at, use the 1.302 -\hgcmd{parents} command. 1.303 +Pour découvrir quelle révision de l'espace de travail en est, utiliser 1.304 +la commande \hgcmd{parents}. 1.305 \interaction{tour.parents} 1.306 -If you look back at figure~\ref{fig:tour-basic:history}, you'll see 1.307 -arrows connecting each changeset. The node that the arrow leads 1.308 -\emph{from} in each case is a parent, and the node that the arrow 1.309 -leads \emph{to} is its child. The working directory has a parent in 1.310 -just the same way; this is the changeset that the working directory 1.311 -currently contains. 1.312 - 1.313 -To update the working directory to a particular revision, give a 1.314 -revision number or changeset~ID to the \hgcmd{update} command. 1.315 +Si vous regardez de nouveau le dessin~\ref{fig:tour-basic:history}, vous 1.316 +verrez que les flèches reliant entreux les \textit{changeset}. Le noeud 1.317 +dont la flèche mène \emph{de quelquepart} est dans chaque cas un parent, 1.318 +et le node dont la flèche mène \emph{à quelquepart} est un enfant. 1.319 +L'espace de travail a un parent de la même manière, c'est ce \textit{changeset} 1.320 +que l'espace de travail contient à ce moment. 1.321 + 1.322 +Pour mettre à jour l'espace de travail d'une révision particulière, 1.323 +indiquer un numéro de révision ou un \textit{changeset~ID} à la commande 1.324 +\hgcmd{update}. 1.325 \interaction{tour.older} 1.326 -If you omit an explicit revision, \hgcmd{update} will update to the 1.327 -tip revision, as shown by the second call to \hgcmd{update} in the 1.328 -example above. 1.329 - 1.330 -\subsection{Pushing changes to another repository} 1.331 - 1.332 -Mercurial lets us push changes to another repository, from the 1.333 -repository we're currently visiting. As with the example of 1.334 -\hgcmd{pull} above, we'll create a temporary repository to push our 1.335 -changes into. 1.336 +Si vous ne précisez pas de manière explicite de numéro de révision 1.337 + 1.338 +la commande \hgcmd{update} mettra à jour votre espace de travail avec 1.339 +le contenu de la révsion \textit{tip}, comme montré dans l'exemple 1.340 +ci dessus lors du second appel à \hgcmd{update}. 1.341 + 1.342 +\subsection{Transférer les modifications à un autre dépôt} 1.343 + 1.344 +Mercurial vous laisse transférer les modifications à un autre 1.345 +dépôt, depuis votre dépôt actuel. Comme dans l'exemple du 1.346 +\hgcmd{pull} ci dessus, nous allons créer un dépôt temporaire 1.347 +vers lequel transférer\footnote{NdT: Les francophones disent souvent 1.348 +``pousser'' tout simplement} nos modifications. 1.349 \interaction{tour.clone-push} 1.350 -The \hgcmd{outgoing} command tells us what changes would be pushed 1.351 -into another repository. 1.352 +La commande \hgcmd{outgoing} nous indique quels changements nous 1.353 +allons transférer vers l'autre serveyr. 1.354 \interaction{tour.outgoing} 1.355 -And the \hgcmd{push} command does the actual push. 1.356 +Et la commande \hgcmd{push} effectue réellement le transfert. 1.357 \interaction{tour.push} 1.358 -As with \hgcmd{pull}, the \hgcmd{push} command does not update the 1.359 -working directory in the repository that it's pushing changes into. 1.360 -(Unlike \hgcmd{pull}, \hgcmd{push} does not provide a \texttt{-u} 1.361 -option that updates the other repository's working directory.) 1.362 - 1.363 -What happens if we try to pull or push changes and the receiving 1.364 -repository already has those changes? Nothing too exciting. 1.365 +Comme avec \hgcmd{pull}, la commande \hgcmd{push} ne met pas à jour 1.366 +le répertoire de travail du dépôt dans lequel il transfère les 1.367 +modifications. (À l'inverse de \hgcmd{pull}, \hgcmd{push} ne fournit 1.368 +pas d'option \texttt{-u} pour forcer la mise à jour de l'espace 1.369 +de travail cible). 1.370 + 1.371 +Qu'est ce qui se passe lorsque vous essayez de récupérer ou de transférer 1.372 +vos modifications et que le dépôt cible a déjà reçu ces modifications ? 1.373 +Rien de bien excitant. 1.374 \interaction{tour.push.nothing} 1.375 1.376 -\subsection{Sharing changes over a network} 1.377 - 1.378 -The commands we have covered in the previous few sections are not 1.379 -limited to working with local repositories. Each works in exactly the 1.380 -same fashion over a network connection; simply pass in a URL instead 1.381 -of a local path. 1.382 +\subsection{Partager ses modifications à travers le réseau} 1.383 + 1.384 +Les commandes que nous avons étudiés dans les sections précédentes 1.385 +ne sont pas limite aux dépôt locaux. Chacune fonction de la même 1.386 +manière à travers une connexion réseau, il suffit de lui passer une 1.387 +URL et non un chemin de fichier local. 1.388 + 1.389 \interaction{tour.outgoing.net} 1.390 -In this example, we can see what changes we could push to the remote 1.391 -repository, but the repository is understandably not set up to let 1.392 -anonymous users push to it. 1.393 +Dans cet exemple, nous allons voir quels changements nous pourrions 1.394 +transférer vers le dépôt distant, mais le dépôt est, de manière tout 1.395 +à fait compréhensible, pas configuré pour accepter des modifications 1.396 +d'utilisateurs anonymes. 1.397 \interaction{tour.push.net} 1.398 1.399 %%% Local Variables: