Mercurial/Git : ne pas "brancher" est une erreur
Par Laurentj le dimanche, novembre 7 2010, 14:07 - Projets - Lien permanent
Et c'est une erreur que j'ai faite pour le développement de Jelix 1.2. Cela a conduit à un gros retard (presque 1 an !) sur la sortie de la version stable, avec toutes les conséquences qu'un retard de la sortie d'une version d'un projet peut avoir.
Pour mon framework, depuis longtemps je voulais y intégrer un système d'installation automatique, qui permette d'installer, d'initialiser (mise à jour de la base de données, de la configuration de l'application...) un module, et aussi de le mettre à jour très facilement.
Au début de l'été 2009, j'ai donc commencé à développer ce nouveau système d'installation de module. Quand j'ai commencé, je pensais que je n'en aurais pas pour longtemps. J'ai donc commencé à commiter les modifications... dans le trunk. Mais plus j'avançais, plus je découvrais des problèmes à résoudre. Et puis une fois qu'il était opérationnel, j'ai découvert à l'usage d'autres soucis, qu'il a fallu corriger. Tout ceci a pris au final beaucoup de temps. En ajoutant les longues périodes où j'étais trop occupé sur d'autres projets, le système d'installation a commencé à être stable qu'en juin dernier !
Parallèlement à ça, j'ai amélioré d'autres composants, des contributeurs ont proposé de nombreux patchs correctifs ou de nouvelles fonctionnalités, tout ça commité... aussi dans le trunk...
Bref, le trunk contenait à la fois des nouveautés et corrections diverses et variées, mais aussi un composant expérimental. Et ce composant impactant le fonctionnement interne du framework, il n'était pas possible de sortir des versions intermédiaires pour que les utilisateurs puissent profiter des nouveautés autre que ce système d'installation. Créer une branche à partir d'un "changeset" antérieur aux premiers commits du système d'installation, en y backportant les autres modifications, ou faire un "backout" de tous les changements apportés par le système d'installation, aurait demandé trop de travail, à l'époque où je me suis rendu compte de mon erreur.
D'habitude, j'essaye toujours d'avoir un trunk "stable", fonctionnel. Mais la sous-estimation du travail sur ce nouveau composant, l'envi de l'intégrer à la prochaine version, et certainement l'enthousiasme que j'avais à le développer, ont fait que je n'ai pas vraiment réfléchi à l'organisation de ce développement. Et au final le trunk a souvent été inutilisable durant cette période. Et je n'ai pas vraiment d'excuses, dans la mesure ou brancher et merger avec Mercurial (ou Git) ne pose en général peu de problèmes (ce n'est pas le cas avec subversion, ça n'a jamais vraiment fonctionner avec moi).
J'aurais donc du développer ce système d'installation dans une branche à part, laissant sur le trunk que les corrections de bugs et améliorations sur les autres parties de jelix. Ça aurait permis de sortir des versions intermédiaires de Jelix à partir du trunk, qui soient opérationnelles (et sans le système d'installation) . Et j'aurais pu continuer le développement du système d'installation dans son coin, pour ensuite intégrer les modifications de cette branche dans le trunk une fois qu'il était utilisable.
Les prochains gros chantiers sur Jelix seront donc développés dans des branches, afin de pouvoir sortir des versions stables de jelix plus régulièrement :-)
Commentaires
Quand tu parles de branches, surtout au niveau de Mercurial/Git . Tu parles d'utiliser les tags internes afin de créer des branches au sein du même dépôt ou alors d'utiliser un dépôt annexe pour le développement.
Je trouve la seconde possibilité bien plus adaptée car elle utilise la décentralisation des dépôts et Mercurial et Git sont justement fait pour ça.
N'empêche que de t'avoir "embêté" régulièrement depuis 2ans avec cet installeur, ça a porté ces (superbes) fruits ! *<:o).
A mes débuts avec jelix j'avais envi de faire un petit "truc" qui permettrait d'installer, via une interface web, des modules ou autres. Mais sans la "vision" jelixienne je me fourvoyais, mais à présent que tu l'as réalisé c'est le grand bonheur !
Encore bravo à toi pour tout ce temps passé sur le framework avec toujours autant de réussite, clarté, disponibilité.
Merci !
Merci pour la transparence.
Il est vrai que pour les petites améliorations, corrections c'est un peu dommage. Mais bon quand on voit tout ce qui arrive avec la 1.2 ....
Je traine souvent des pieds pour passer au version corrective, même si je n'ai pas beaucoup de modifications sur le framework, mais c'est un peu casse pied de reproduire à chaque fois les modifs quand on commence à avoir quelques sites en maintenance.
Bienvenue à cette 1.2
Manu
@seza il ne faut pas confondre tag et branches. un tag (en tout cas au sens mercurial), est un simple alias à un changeset.
Je suppose que tu parles d'utiliser les branches internes (ou appelées aussi branches nommées) ou externes (clones). Utiliser l'un ou l'autre, ça revient au même au final, lors de la fusion sur le trunk. La différence est qu'utiliser un clone ne pollue pas le dépôt central si au final, le développement expérimental est annulé. En tout cas sur mercurial, car sur git, je crois qu'il est possible de supprimer totalement une branche nommée. (quoique, possible qu'il y ait un plugin pour mercurial pour faire ça)
@foxmask @m@noo : merci à vous aussi :)
Oui oui je parlais des branches nommées, j'ai écrit mon commentaire à la va vite et j'étais dans le fil de ma pensée et absolument pas vu la confusion que j'avais faite.
C'est clair qu'il y a maintes manières de faire du " branching " avec Mercurial et chaque manière à ses avantages et inconvénients. D'ailleurs, je crois bien de mémoire, on peut utiliser les bookmarks avec Mercurial pour créer une branche interne à un dépôt qui une fois " fermée/supprimée/mergée " disparait complètement du log.
À la première lecture de ton billet j'avais le sentiment que tu te fixais sur une manière de faire du branching " avoir un trunk sans branche nommée est un erreur ". D'où mon commentaire et à la lecture de ton commentaire j'en retire plutôt que tu te centrais sur l'intérêt de faire des branches et non sur la manière etc.. Bref, je t'ai polué d'un com. inutile ;)
ça s'applique aussi aux projets sous subversion, et ça fonctionne très bien !
Dans le SVN book c'est la "feature branche"
http://svnbook.red-bean.com/en/1.2/...