Commits

Frederic De Groef committed fdd96b2

notes on THG's sync tool

Comments (0)

Files changed (1)

 
 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.
+mercurial 1.6. Les éléments de l'interface pertinents pour les scénarios
+présentés sont présentés de manière succinte. Pour plus d'information,
+se référer au `manuel de TortoiseHG <http://tortoisehg.bitbucket.org/manual/1.1/>`_.
 
 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.
+d'un autre outil. Un exemple de *merge* est présenté dans ce document.
 
 
 
 
 
 Les modifications doivent maintenant être enregistrées, à l'aide d'un
-*commit* (clic droit, *Commit*):
+*commit* (clic droit, *Hg Commit*):
 
 .. figure:: ../images/4_commit_1.png
    :align: center
 
 Une fois cloné, le 1er développeur modifie ses fichiers localement et 
 *commit* ses changements. Il peut ensuite transmettre ses changements
-au dépot central ``project-main``, à l'aide l'outil *Synchronize*. Il
-effectue un *push*:
+au dépot central ``project-main``, à l'aide l'outil *Synchronize* (clic droit, *TortoiseHG*, *Synchronize*). 
+
+Dans cet outil, on considère quatre boutons principaux. *Incoming*
+permet de visualiser les changements présents dans le dépot distant
+(dans notre cas, ``project-main``). *Pull* importera ces changements
+dans le dépot local. 
+Symétriquement, *Outgoing* permet de prévisualiser les changements qui seront transmis au
+dépot distant, et *Push* de les transmettre effectivement.
+
+Il est possible de choisir le répertoire distant avec lequel se
+synchroniser via la liste de séléction (précédée par les boutons *Repo:*
+et *Bundle:*. Par défaut, un dépot cloné affiche le dépot original
+comme option de synchronisation. Il est possible d'ajouter des dépots
+à cette liste (Bouton *Configure*, section *Synchronize*).
+
+
+Retour au scénario. Le 1er développeur utilise l'outil de
+synchronisation pour effectuer un *Push* de ses changements vers le
+dépot central:
 
 .. figure:: ../images/7_push_dev1.png
    :align: center
    Résultat d'un *push* sur le dépot central, sans conflit.
 
 
-La fonction *outgoing* permet de vérifier les *changesets* qui seront
-transmis lors du *push*. Symétriquement, la fonction *incoming* permet
-de vérifier les *changesets* qui seraient transmis lors d'un *pull*.
-
-
 Considérons maintenant le cas du second développeur, pour lequel le
 dépot aura changé depuis la dernière fois qu'il y a accédé.
 
 
 En pratique, il est possible de forcer la
 synchronisation, et donc la création de cette seconde *head*, à
-l'aide de la commande ``hg push --force project-main``.
+l'aide de la commande ``hg push --force project-main``. Il est
+important de noter qu'aucune information ne sera perdue en forçant
+cette synchronisation. [#svn_sync_fail]_
 
 
 Toutefois, comme le conflit devra être résolu d'une manière ou d'une
 
 .. [#vs] http://www.microsoft.com/visualstudio/en-us/
 
+.. [#svn_sync_fail] Avec un système comme svn, la résolution aurait
+   été obligatoire **avant** le *commit*. Cette simple opération, qui
+   en pratique se produit des dizaines de fois par jour, illustre
+   les avantages et la flexibilité d'un DVCS.
+
 .. [#kdiff3] KDiff3 offre le paradigme de *merge* idéal pour éviter les
    erreurs. La raison principale est qu'il présente les 3 versions du
    fichier en cours de résolution (le premier ancêtre commun, et les deux