• # hg

    Posté par (site web personnel) . En réponse au sondage Mon logiciel de Logiciel de gestion de versions favori est :. Évalué à 5.

    admettons que svn est en tête pour des raisons historiques (sinon pourquoi ?)

    Bazaar se fait laminer par presque tout le monde (nan mais sérieux, quelqu'un l'utilise par plaisir celui-là ?)

    Mercurial par contre est totalement à la ramasse par rapport à git
    Pourquoi ?
    - git c'est fun ?
    - git c'est roots ?
    - git il fait le café ?
    - mercurial est à la traine ?
    - mercurial n'est pas pratique ?
    - mercurial est trop proche de svn ?
    (cette belle indentation de question me rappel un de mes anciens chefs qui réorganisait constamment son code pour avoir au maximum sous cette forme, la ligne suivante toujours plus longue que la précédente...)


    Bon, il est vrai que je tape souvent sur mercurial. Mais je viens de comprendre un truc (enfin) et j'en profite pour le partager avec vous tous : dans mercurial une branche n'existe que par la présence d'un commit. En gros la branche est une metadata du commit.
    Donc si dans git il est possible de créer par exemple 3 branches locales dans lesquelles travailler plus tard (histoire de préparer son taff quoi), dans mercurial tant qu'on a pas de commit, la branche n'existe pas. Donc si on crée (ou croit créer...) 3 branches, lorsqu'on va vouloir switcher de l'une vers l'autre on va avoir un zoli message nous disant que ça ne fonctionne pas, que la branche est inexistante.
    ☿ hg branch feature1
    marked working directory as branch feature1
    ☿ hg up default
    0 files updated, 0 files merged, 0 files removed, 0 files unresolved
    ☿ hg up feature1
    abandon : unknown revision 'feature1' !

    Ceci explique que lorsqu'on tente d'utiliser hg comme git (y compris avec bookmarks, localbranch, tasks, etc) ça ne marche jamais...

    Finalement, hg et mercurial, s'ils sont équivalents, n'ont pas du tout la même façon de bosser.
    Dans git, on va créer des branches locales nommées, souvent, et parfois à l'avance (histoire d'organiser).
    Dans mercurial on va coder et, si besoin, on va brancher là où on le souhaite, mais au dernier moment je pense.
    Et d'ailleurs, le fonctionnement de base de mercurial fait qu'on ne va pas la nommer, juste utiliser la révision initiale (ou alors utiliser bookmarks, qui permet "simplement" de nommer une révision en fait)

    Bon, dans les deux cas on arrive au même résultat. Mais je pense que si on vient de git et qu'on tente d'utiliser hg de la sorte, on est très vite déçu par hg. Par contre, en comprenant un peu plus comment ça marche, ben c'est intéressant comme manière de travailler. Le point noir par contre c'est que ça force à connaître un peu plus comment fonctionnent les branches, les commits dans mercurial.


    Voilou, c'était juste pour dire que je commençais enfin à comprendre comment mercurial fonctionne (et peut-être même qu'un jour j'arrêterai de troller dessus...)