Commits

Frederic De Groef  committed 0200d83 Merge

merge

  • Participants
  • Parent commits 5883d82, 262bba0

Comments (0)

Files changed (4)

File source/index.rst

 Remarque générale
 --------------------------------------------------------------------------------
 
-Ce document n'est pas destiné a être un guide d'utilisation complet
+Ce document n'est pas destiné à être un guide d'utilisation complet
 pour les DVCS et Mercurial. Nous présentons ici le minimum requis
 pour démarrer et être rapidement productif avec l'outil. Pour les
-utilisations avancées, vous êtes invités à consulter les références et resources
+utilisations avancées, consulter les références et resources
 additionnelles.
 
 

File source/mercurial.rst

 Dossier contenant un sous-dossier ``.hg``. Ce dossier
 contient l'entiereté de la base de données de révisions du
 projet. Ceci comprend le contenu des fichiers à chaque révision,
-l'historique des commits. Sous windows, ce dossier est caché par défaut.
+l'historique des commits. Sous Windows, ce dossier est caché par défaut.
 
 
 
 Un état de travail courant du projet. Concerne tous les
 fichiers en dehors du dossier ``.hg``. Ce sont ces fichiers qui seront
 édités, éxécutés, compilés pendant le développement. ``hg update`` permet de changer les fichiers
-de la working copy vers une autre révision.
+de la *working copy* vers une autre révision.
 
 
 
 Révision et *changeset*
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Une révision est le snapshot d'un état du projet. Avec Mercurial, une
+Une révision est un *snapshot* d'un état du projet. Avec Mercurial, une
 révision est identifiée par un *changeset*.
 
-rev number VS changeset: Une importante distinction. Chaque commit est
-accompagné de numéros d'identification:
+Il existe une importante distinction pour l'identification d'une
+révision. Chaque *commit* est accompagné de numéros d'identification:
 
 ::
 
 
 Il faut distinguer 2 parties, de part et d'autre du ``:``
 
-La première est le *revision number*. Il s'agit d'un compteur. Ce
+La première est un *revision number* (ici, le nombre 4). Il s'agit
+d'un compteur local. Ce
 numéro ne doit pas être utilisé pour identifier un changeset à travers
-plusieurs dépots.
+plusieurs dépots, car différents *changesets* dans différents dépots
+pourront la même valeur (ce sera le cas lors de modifications concurrentes).
 
 La seconde partie est quant à elle unique. Il s'agit d'un hash `SHA-1 <http://en.wikipedia.org/wiki/SHA-1>`_
-sur les différences entre 2 révisions. C'est de cette manière que
+sur les différences entre 2 révisions. C'est avec ce *changeset ID* que
 mercurial identifie sans ambiguité une révision à travers de mutliples
-dépots sujets à modifications en parallèle (ou branches).
+dépots sujets à modifications en parallèle.
 
 
 

File source/revisionning.rst

    se disant qu'on en aura peut être besoin plus tard. Ajout de la date
    à côté pour s'en souvenir
 #. au fil du temps, le projet contient principalement du code mort,
-   commenté. Les fichiers deviennent innavigables.
-#. une autre approche pourrait être de faire un backup de la version
+   commenté. Les fichiers deviennent difficilement navigables.
+#. une autre approche pourrait être de faire une copie de la version
    fonctionnelle avant d'y apporter des mofidication
     * ``foo.cpp`` -> ``foo.cpp.20101023``
     * à un moment il faudra soit accepter le nouveau fichier, soit

File source/usage.rst

 Nous présentons ici la stratégie recommandée pour un travail seul ou
 en petites équipes.
 
-Dans ces exemples, nous utilisons TortoiseHG 1.1.1 (mercurial 1.6).
+Dans ces exemples, nous utilisons TortoiseHG 1.1.1 (mercurial
+1.6). Les exemples en ligne de commande sont réalisés sous MacOSX avec
+mercurial 1.6.
+
+La plupart des commandes de l'outil *command line* ``hg``
+sont traduites en une entrée dans le menu principal de TortoiseHG.
+Certaines opérations, comme le *merge*, sont accessibles par le biais
+d'un autre outil. Un exemple de *merge* est présenté plus bas dans ce document.
+
 
 
 Un dépot référent central 
 
 Un *workflow* de type centralisé est tout à fait
 supporté par un DVCS, et plus simple à mettre en oeuvre avec mercurial.
-Dans ce mode, on utilise un dépot "référent". Chaque developpeur commence par cloner ce dépot.
-Un developpeur fait des changements, transmet ses modifications sur le dépot central.
+Dans ce mode, on utilise un dépot "référent". Chaque développeur commence par cloner ce dépot.
+Un développeur fait des changements et transmet ses modifications sur
+le dépot central. 
 
 
-Création de projet 
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Création de dépot et ajout de fichiers
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Command line:
+*Command line*
 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 
+La commande de création d'un dépot dans un répertoire est ``hg
+init``. Cette commande initialise la base de données mercurial. Aucun
+fichier n'est révisionné après création du dépot.
+
 ::
 
-
     $ mkdir project-main
+    $ ce project-main
     $ hg init
     <création de file.txt>
     $ hg add file.txt 
     $ hg commit -m "added a file"
 
 
-Avec TortoiseHG:
+TortoiseHG
 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 
 Dans un répertoire vide, ou avec des fichiers sources non-révisionnés,
    :align: center
    
    Création d'un dépot mercurial depuis un répertoire de
-   sources (``hg init``)
+   sources
 
 
 Après initialisation, le dossier contenant la base de donées mercurial
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 
-* Command line:
+*Command line*
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+
+Dans cet exemple, un développeur commence par cloner le dépot central,
+y ajoute un second fichier.
 
 ::
 
     $ hg commit -m "did some work"
 
 
+Il transmet ensuite ses changements sur le dépot central.
 
 ::
  
      $ hg push project-main
 
 
-* TortoiseHG:
+*TortoiseHG*
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 
 Pour cloner un répertoire accessible localement, clic droit sur ce
 répertoire, et accéder à l'entrée *Clone...*
 tentera une synchronisation via la command ``hg push``.
 
 
-* Command line: 
+*Command line*
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 
 ::
 
 
 
 
-* TortoiseHG:
+*TortoiseHG*
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 
 .. figure:: ../images/8_push_conflict.png
    :align: center
 *head*. En d'autres termes, on importe les changements transmis par le
 premier développeur.
 
-* Command line:
+*Command line*
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 
 ::
 
     $ hg pull project-main
 
 
-* TortoiseHG:
-
+*TortoiseHG*
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 
 .. figure:: ../images/9_pull_conflict.png
    :align: center
 
 La résolution des conflits se fait comme suit:
 
-* Command line:
+*Command line*
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 
 S'il n'existe que 2 *heads* dans un dépot, la commande hg
 merge sans paramètre suffit. Au delà, il faudra préciser le numéro de
 
 
 
-* TortoiseHG: 
+*TortoiseHG*
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 
 Avec TortoiseHG, il faut explicitement spécifier les *heads* à merger
 depuis le *Repository Explorer*.
 tout de même bénéficier des avantages de mercurial pour leur travail
 au jour le jour.
 
-Les détails sont décrits à l'`adresse suivante <http://mercurial.selenic.com/wiki/WorkingWithSubversion>`_.
+Les détails sont décrits à l'`adresse suivante
+<http://mercurial.selenic.com/wiki/WorkingWithSubversion>`_.