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 ;-).

"Forkez" Jelix !

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