Jelix : de Mercurial à Git
Par Laurentj le jeudi, septembre 1 2011, 08:57 - Logiciels - Lien permanent
Depuis deux ans déjà, j'ai complètement abandonné subversion et utilisé Mercurial pour gérer le code source de mes projets. J'avais choisi Mercurial au départ parce que je devais l'utiliser pour contribuer à Firefox. J'avais alors apprécié le produit et l'avais adopté pour mes autres projets personnels. Pour les projets professionnels comme chez Zoomorama, et ou pour Jelix, nous (moi et mes collègues ou les contributeurs) avions étudié bien sûr Git avant de choisir Mercurial. À l'époque, Mercurial paraissait plus simple d'utilisation : des commandes plus claires, plus concises, moins verbeuse. Il avait aussi un meilleur support multi-plateforme en particulier sous windows. Ce dernier critère me paraissait essentiel par exemple pour Jelix, car j'avais des contributeurs sous Windows.
Au fil du temps, en particulier dans le projet Jelix, la gestion des branches de Mercurial me paraissait de plus en plus limitante. Une branche ne pouvant être supprimée, il est préférable de cloner le dépôt pour développer une nouvelle fonctionnalité, de manière d'une part à garder une branche "officielle" relativement stable, et d'autre part pour ne pas se retrouver au bout d'un moment avec 50 branches qui ne servent à plus rien. En fait, dans Mercurial, il est tout à fait naturel et normal de cloner un dépôt, un clone devenant implicitement une branche.
Mais à la longue, cette manière de faire devient assez lourde, on se retrouve avec de multiples clones sur son disque, même si on peut les supprimer quand on n'en a plus besoin.
L'alternative alors dans Mercurial est d'utiliser les "queues" de Mercurial, alias mq. C'est un système qui permet de gérer une pile de patchs. C'est quelque chose que j'apprécie particulièrement, et très utile pour les projets où le mode de collaboration impose la soumission de patchs pour être revues, avant de les committer dans le dépôt du projet. C'est ainsi que fonctionne le projet Mozilla et Jelix jusqu'à maintenant. L'autre avantage de mq est que cela évite d'avoir de multiples commits dans l'historique : on a au final un seul commit correspondant à un patch complet[1] qui fonctionne, puisqu'il a normalement été revue par une personne tierce.
Cependant cela n'élimine pas un autre souci qui m'agaçait de plus en plus dans la gestion du projet, et qui est lié à la revue de code : il est compliqué de commenter les patchs. Que ce soit dans le Trac de Jelix ou sur Bitbucket, site sur lequel est hébergé le code source de Jelix, il n'y a pas la possibilité de commenter ligne à ligne. Ça alourdi la revue de code. Ça alourdi le processus de contribution.
À propos de Bitbucket, le site n'est pas trop mal. Mais les fonctionnalités ne sont pas aussi évoluées que son concurrent principal, Github. Il évolue, mais pas aussi vite que Github, et j'ai même l'impression que depuis son rachat par Atlassian, le projet est un peu moins actif. Des fonctionnalités comme la revue de code sont attendues depuis des lustres par beaucoup d'utilisateurs, mais on ne voit toujours rien venir.
Autre point, le couple Git/Github semble maintenant avoir une popularité qui surpasse celle des autres systèmes de "versionning".
J'ai donc décidé, pour Jelix, après en avoir discuté avec mes contributeurs, de passer à Git, et d’héberger le projet sur Github. J'ai été convaincu par la gestion des branches de Git, beaucoup plus souple. En effet, pour les utilisateurs de Mercurial, sachez qu'une branche dans Github s'apparente à un bookmark dans Mercurial (mais Bitbucket ne prend pas en charge les bookmarks). De plus, Github est fonctionnellement beaucoup plus puissant, avec un système de revue de code bien conçu. Cela va nous permettre d'avoir un "workflow" plus fluide pour les contributions, plus simple.
Bref, un nouveau chapitre se tourne dans l'histoire du projet Jelix, qui est de plus marqué par la sortie de la première version candidate de Jelix 1.3 ;-).
Notes
[1] pour les grosses contributions, on peut avoir plusieurs commits correspondant à plusieurs étapes de la modification, mais l'historique reste tout de même clair
Commentaires
J'ai lu un tweet de signap ce matin qui cite un poste sur g+ qui lui-même cite l'auteur de hg-git dont le billet est http://scottchacon.com/2011/08/31/g... et qui en dit long sur la vitesse à laquelle évolue GitHub tous les jours.
Pour ce qui est des "queues" mercurial, c'était pas mal. Là avec Git il faut faire un rebase pour éviter de push x commit "pour rien" pour n'en avoir qu'un. C'est une autre façon de faire pour arriver au même résultat. Faut s'y faire :)
Il y a également la commande strip qui permet de supprimer des commit (et donc des branches)
Mais l'une des grosses différences entre mercurial est git se trouve au niveau de la manipulation des commits poussés : Sur mercurial tu ne peux pas supprimer/déplacer ce que tu as déjà poussé, par exemple, si tu pousse tes modifications sur un autre repository, puis que tu manipules des commits (avec MQ, strip, rebase ou autres) et que tu repousse tes modifications, alors, ce que tu as déplacé en local s'ajoutera aux commits précédents tu te retrouvera donc avec des doublons.
C'est un inconvénient : une fois une "connerie" poussé, tu ne peux pas revenir dessus (a moins de réparer en local sur touts les repository ayant synchronisé la connerie)
Mais c'est aussi un avantage : (c'est principalement pour cette raison que google code a choisi mercurial) Si un développeur supprime par inadvertance (ou manque de connaissance dans l'outil) une branche il ne peux pas pousser la suppression sur les autres repositories
ce second cas m'est arrivé sur un projet, un jeune developpeur ne connaissant pas l'outil et ayant eu un conflit lors d'un PULL à ignore le conflit, et fait un FORCE-PUSH du coup, il purement et simplement supprimé les commits en conflit sur le repository "public"
Comme on travail souvent avec des prestataires qui ne maîtrisent pas toujours l'outil, on a fait le choix de travailler avec mercurial, même si je te rejoins sur le fait que Git est plus puissant.