Cher journal,
voici mes réflexions sur les DSCM (Distributed Source Code Management), enfin surtout Git et Mercurial, et tant qu'à faire, j'aimerais bien avoir ton avis sur la question.
Je vais attaquer un projet pour lequel je vais utiliser un DSCM (non, je n'ai vraiment pas envie d'utiliser Subversion), et je me suis donc penché sur le sujet. D'un point de vue technique, les 2 gagnants sont Git et Mercurial. Du moins, c'est l'impression que j'en ai, et elle est partagée avec d'autres personnes avec qui j'en ai discuté. Je ne nie pas que les autres (darcs, bazaar-ng, etc.) aient des qualités, mais ils m'intéressent moins que Git et Mercurial. Coté Mercurial, je vois comme avantage le fait que je l'ai déjà utilisé (ce qui n'est pas le cas de Git) et que son utilisation est réputée plus simple. Ca ne fait pas très lourd, surtout qu'on m'a dit que Git a fait de gros progrès sur ce point avec les dernières versions.
De l'autre coté, j'ai l'impression que Git est en train de marquer des points dans la guerre des DSCM, et de venir de plus en plus populaire. Depuis les annonces de Mozilla et OpenSolaris, je ne crois pas avoir croisé beaucoup de projets qui utilisent Mercurial, alors que je vois régulièrement des dépôts Git (utilisé pour du code, mais aussi pour du packaging et de la doc). Du coté des hébergeurs, même topo : Tuxfamily a récemment annoncé le support des dépôts Git, et je connais des hébergeurs spécialisés dans Git comme GitHub, mais pour Mercurial, je ne pense pas en avoir croisé.
Dans la communauté Ruby on Rails, cela me semble encore plus frappant. La manière plus ou moins officielle de distribuer des plugins est d'offrir un accès anonyme à un dépôt svn (en lecture seule, l'accès). Mais plusieurs développeurs de plugins connus utilisent Git pour développer les plugins, et synchronisent le svn juste pour les releases. Il existe également des projets visant à utiliser les plugins quand on utilise Git (comme Giston ou Git-rails). Il me semble que capistrano possède également un module pour Git. Et pour Mercurial ? je n'ai rien vu, mais alors rien de rien.
Bref, j'ai l'impression que Git est en train d'écraser la concurrence, ce qui veut dire que le développement de Git va surement avancer plus vite que celui de Mercurial, qu'on trouvera de plus en plus d'outils pour Git, et surtout, que des potentiels contributeurs auront plus de chances de connaitre Git que Mercurial. Je pense que je vais choisir Git surtout pour ce dernier point, car j'espère attirer des contributeurs dans les prochains mois et je ne voudrais que le DSCM soit le moins possible un point de bloquage.
Et vous, chers lecteurs, vous-en pensez quoi ?
> Lire le journal (111 commentaires, moyenne: 2,5).
Vous avez demandé le commentaire #904405.
Cette page a été générée par Templeet en 0.0526s (dont 0.0056 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Mes 2 centimes
Déjà, il faudrait être bien sur qu'un DSCM est ce qui est le mieux adapté à tes besoins. Les DSCM deviennent à la mode mais posent également des problèmes d'organisation. Ce n'est plus le logiciel qui centralise, mais une personne : tout le monde doit en être conscient. Il y a des projets vraiment communautaires, ou simplement avec plusieurs mainteneurs de "même poids", qui n'accepte pas cette philosophie. L'autre point, technique, est qu'avec un DSCM, tu auras plus de conflits à gérer qu'avec un SCM classique. Chaque personne pouvant faire sa sauce chez lui, cela complique les fusions de code.
Cela dit, que choisir entre Git et Mercurial ?
C'est probablement plus une affaire de gout qu'autre chose.
Pour ma part, j'ai choisi Git depuis un moment déjà. Il était plutôt complexe à utiliser directement à ses débuts mais il a fait d'énormes progrès dans le domaine. Pour moi, Git a passé l'épreuve du feu. Avoir été choisi pour gérer le kernel Linux, Xorg ou Wine est une preuve indéniable de qualité originelle, ou du moins acquise. De nombreux projets et forges l'on choisi. C'est rassurant : s'il y a des bugs, ils seront vite repérés et corrigés. D'autre part, les outils tiers se développent effectivement.
La critique que je ferai sur Git est le fait qu'il soit difficile de remonter dans l'historique d'un fichier. Le modèle de gestion est plutôt basé sur l'historique de tout l'arbre des sources par patches. Si tu veux suivre un seul fichier, c'est donc un peu compliqué. Si tu veux suivre l'évolution de ton projet dans sa globalité, c'est simple.
Je connais très mal Mercurial, je ne vais donc pas en parler ici. Je ne l'ai pas choisi car je ne suis pas très fan de Python (surtout sur un serveur) et je n'ai pas très bien compris l'intérêt de l'utiliser pour coder un DSCM sachant qu'on peut très bien faire sans. Mais bon, l'égout et les couleuvres...
[^]Re: Mes 2 centimes
Effectivement, il semble que Git soit en train de gagner du terrain par rapport à Mercurial, et son utilisabilité s'est bien améliorée dans les dernières versions.
Un point qui reste bien différentiateur est le support Windows, sous lequel Mercurial marche très bien, alors que pour Git il y a un écart sensible par rapport à la version Linux.
(Moi j'utilise un peu les deux pour mes projets perso.)
[^]Re: Mes 2 centimes
> Je ne l'ai pas choisi car je ne suis pas très fan de Python (surtout sur un serveur) et je n'ai pas très bien compris l'intérêt de l'utiliser pour coder un DSCM sachant qu'on peut très bien faire sans.
Mais git utilisant perl ne te choque pas ?
[^]Re: Mes 2 centimes
> Mais git utilisant perl ne te choque pas ?
Puisque l'utilisation de python le choque, il est normal que l'utilisation de perl ne le choque pas.
[^]Re: Mes 2 centimes
Git écrit en perl, c'est une blague ...hein ?
[^]Re: Mes 2 centimes
Le noyau est en C. Les wrappers, eux, sont partagés entre shell et perl.
19 perl pour 54 shell au moment où je compte.
[^]Re: Mes 2 centimes
Qu'entends tu par wrapper ?
Est ce je peux utiliser Git simplement en appelant que des fonctions noyau.
Sinon ca me rappelle la première version de CVS en shell sur laquelle un fork avait été fait pour tout réécrire en C.
Ou encore ces infâmes hacks de Tom Lords sans queue ni tête qui ont données naissance à toutes cette ribambelles de forks mieux concus.
Vive Mercurial et Python alors.
Ou encore SVN écrit entièrement en C en se basant sur l'apache Portable Library à des fins de portabilité.
Ca en est où git avec windows à propos ?
Pas facile de rendre un portage aussi performant lorsqu'il n'a pas été prévu pour à la base.
Python aussi est portable.
[^]Re: Mes 2 centimes
Je connais très mal Mercurial, je ne vais donc pas en parler ici. Je ne l'ai pas choisi car je ne suis pas très fan de Python (surtout sur un serveur) et je n'ai pas très bien compris l'intérêt de l'utiliser pour coder un DSCM sachant qu'on peut très bien faire sans. Mais bon, l'égout et les couleuvres...
Parce que c'est plus rapide pour developper, que un scm bien foutu est très vite IO-bound (le core de mercurial est en C, le reste est en python, au final c'est pas si différent de git, sauf que le core est plus petit :)
Sinon perso mon problème avec git c'est le fait qu'il n'y ait pas d'historique au niveau fichier et que la taille prise par le dépot (j'aime pas l'architecture avec d'un coté on a un truc très gros de l'autre on a des packs qu'il faut faire manuellement et qui peuvent potentiellement etre dangereux pour l'historique -- on reecrit l'historique).
Dans mercurial je suis pas très fan de la gestion des branches (in-repo) si on utilise que des clones pour developper ses branches ca rox (et avec les hardlinks ca prend pas trop de place).
(D'ailleurs mercurial est aussi utilisé par des "grands": mozilla, sun, xen, etc)