Blog them all

Les gestionnaires de source (SCM) il y a quelques années étaient centralisés (CVS, puis Subversion) mais on a désormais des outils bien plus puissants, décentralisés, et qui permettent plus de souplesses (DSCM). Ils sont de plus bien plus rapides. Parmi les acteurs actuels du marché, on a deux gagnants potentiels : GIT, développé en C et utilisé par le noyau Linux (et développé initialement par Linus lui-même) et Mercurial, développé en Python et qui semble plus propre et plus facile d’accès que GIT (on a eu arch, SVK, bazaar, mais ils ne semblent plus aussi actifs).

version divx de la vidéo.

Pour ceux qui sont intéressés par ces GIT, cette vidéo est à voir. Git a été développé par Linus lui-même après avoir utilisé BitKeeper pendant plusieurs années. BitKeeper est propriétaire, mais leurs auteurs autorisaient les projets “open source” à utiliser gratuitement ce gestionnaire. D’après Linus, c’était le seul outil utilisable pour le noyau Linux, et comme il préfère utiliser un logiciel propriétaire qui marche, plutôt qu’un projet libre qui ne marche pas (et moi donc)… (note : le résumé de la vidéo est que Linus déteste CVS, SVN, qu’il apprécie BitKeeper (sur lequel il a globalement pompé les workflows), et que ceux qui ne sont pas d’accord avec lui sont stupides et laids).

Néanmoins comme la levée de bois verts était de plus en plus importante au sein de la communauté et les tensions qui en découlaient de plus en plus pesantes, les auteurs de BitKeeper et Linus ont convenu qu’il fallait mieux que Linus se mette à utiliser autre chose. Après avoir regardé les gestionnaires de sources qui soient :

1. distribués
2. rapides (performants)
3. puissent assurer que le code injecté soit correct lors de son téléchargement ultérieur (sécurité du code)

… et il n’en restait aucun (monotone se rapprochait de ça, mais était bien trop lent d’après Linus). Il a donc commençé à développer GIT en C, pendant qu’en même temps le projet Mercurial était lançé. Les deux ont les mêmes objectifs, et ils ont tous les deux beaucoup évolué depuis. Mozilla utilise Mercurial (liste des projets qui utilisent Mercurial), pendant que le noyau Linux utilise GIT.

Comme l’indique Thomas, Linus passe un peu trop son temps à cracher sur les outils concurrents, mais ceux qui lisent Linus depuis longtemps connaissent son attitude de “tout le monde a tort sauf moi” (mais ça ne l’empêche pas d’être parfois vrai). La vidéo de Linus est aussi évoquée dans ce billet avec quelques commentaires intéressants,

Dans la vidéo Linus évoque des points qui sont tellement vrai, et qui résume l’importance du distribué pour ces outils (et qui s’applique à GIT comme à Mercurial):

• On travaille sur une nouvelle fonctionnalité. On pense qu’elle nous prendra 6H, mais en vérité on ne le sait pas vraiment. À la fin de la journée la fonctionnalité n’est pas terminée, et au final on aura mis 3 jours. Entre temps on n’a fait aucun commit pour ne pas casser le repository central ou avoir une instabilité du repository qui fera gueuler tous les autres développeurs. Avec un DSCM on peut commiter tranquillement dans sa version locale, pour envoyer les modifications une fois tout le code testé et terminé. On peut même envisager de développer cette fonctionnalité dans une branche locale invisible aux autres développeurs, et continuer de développer la branche principale indépendemment si besoin est.
• La gestion de branches centralisées (comme avec SVN ou CVS) est un vrai problème. Comme tout le monde les voit, et on n’en fait donc pas souvent, pour ne pas polluer le repository central. De plus on n’a pas forcément envie que les autres développeurs voient certains travaux temporaires. En décentralisant la gestion des sources, on peut enfin commiter en étant déconnecté (et faire tout le reste). On peut avoir des branches locales pour tester de nouvelles fonctions, sans polluer les autres. On peut même envisager une branche par fonctionnalité.
• Avec un DSCM on peut prendre un logiciel libre et en diffuser une version modifiée si l’auteur du logiciel n’a pas voulu intégrer nos fonctionnalités, et continuer de développer sur sa version locale du logiciel tout en mergeant régulièrement la version originelle de l’auteur avec la notre.

Git et Mercurial peuvent être utilisés de multiples manières, à la CVS avec un serveur central sur lequel toutes les modifications sont envoyées, ou sans serveur central. La méthode qui semble être utilisée par les utilisateurs de GIT et qui s’adaptera bien pour les projets “Open Source” (Logiciels Libres) est d’avoir votre repository privé sur lequel vous travaillez et vous commitez (votre machine du bureau probablement), puis un serveur public sur lequel vous “pushez” vos travaux une fois que vous souhaitez les diffuser (et accessoirement qui vous sert de backup de vos travaux). Ce serveur public est accessible en HTTP par les autres contributeurs, et vous y accédez en SSH. Les contributeurs ont la même configuration, et vous envoie des patches par mails (par le biais d’une mailing list par exemple), et pour ceux qui contribuent fréquemment vous ajoutez leur repository public dans votre repository local, pour pouvoir télécharger leur version quand ils vous le proposent (quand ils ont développé une fonctionnalité par exemple). S’il arrivait que vous abandonniez votre projet, un contributeur régulier pourrait simplement proposer aux autres de venir se greffer désormais sur son repository public et plus sur le votre.

Pour les projets propriétaires ou d’entreprises, on peut envisager d’autres configurations. Pour une équipe de 10 développeurs sur un même réseau :

• Chaque développeur a un repository local (rapide pour les accès disque), et il peut envoyer ses commits sur un GIT distant (serveur local utilisé par tout le monde), accessible en HTTP (seulement en local, le réseau entreprise étant évidemment doublement firewallisé) pour les autres développeurs du groupe. On aura donc par exemple http://git.localdomain.com/notre_super_logiciel/user1/projet.git http://git.localdomain.com/notre_super_logiciel/user2/projet.git, etc, pour autant de développeurs. Ça facilitera le backup, il suffira de prêter attention à ce serveur, et non à chaque station de travail (et chaque développeur sera libre d’installer ce qu’il souhaite, Linux Ubuntu, Debian, Mandriva, *BSD, etc).
• Un repository local “maître” sur lequel tout le monde peut se raccrocher. Seul le chef de projet ou les développeurs seniors ont un accès en écriture dessus.
• Une liste de diffusion locale sur laquelle les développeurs envoient leurs patchs, ou proposent de télécharger leur repository personnel public quand ils ont terminés une fonctionnalité.
• Si plusieurs développeurs sont attribués à une fonctionnalité spécifique importante, ils pourront travailler en groupe indépendamment sans gêner les autres développeurs, dans une branche qu’ils se partageront entre eux, ceci sans polluer le repository central “maître”. Par nouvelle fonctionnalité on entend aussi “nouvelle version du logiciel pour voir s’il ne serait pas plus rapide de faire complêtement différent”.

Pour être complet sur les DCSM, il y a une vidéo sur Mercurial mais je trouve son auteur moins percutant, je ne suis pas allé jusqu’à la fin (update: finalement la vidéo est pas mal, allez jeter un oeil), et voici une autre vidéo sur Mercurial de Bryan O Sullivan. Le site de Mercurial est complet, vous y trouverez comment faire vos développements à la manière du noyau Linux, à la manière de CVS (même si c’est déconseillé), ou pour une entreprise avec un développement contrôlé.

Au final mon coeur pencherait plutôt vers Mercurial, qui donne la sensation d’être fait proprement, rapide, avec pas mal de documentations. Et vous, quel outil de gestion de source décentralisé utilisez-vous ?

This entry was posted on Tuesday, September 4th, 2007 at 12:00 pm and is filed under Uncategorized | . You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.