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 #904444.
Cette page a été générée par Templeet en 0.0512s (dont 0.0057 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Idées fausses
Salut !
Je me permet de corriger quelques idées fausses véhiculées dans ton journal :
Depuis les annonces de Mozilla et OpenSolaris, je ne crois pas avoir croisé beaucoup de projets qui utilisent Mercurial
Sur la page d'Accueil de Mercurial on peut lire :
2007-12-12 NetBeans migrates to mercurial
2007-12-05 OpenJDK (aka Java) switches to Mercurial
2007-11-10 AsciiDoc has switched from Subversion to Mercurial
2007-04-20 Xine has switched from CVS to Mercurial.
Franchement du point de vue "qui a le plus de gros projets qui ont migré vers moi" Git et Mercurial sont équivalents.
je connais des hébergeurs spécialisés dans Git comme GitHub, mais pour Mercurial, je ne pense pas en avoir croisé.
Je reconnais qu'il y a moins d'hébergement Mercurial que Git, mais il y en a. http://sharesource.org/ est un bon exemple. De plus, comme Git, Mercurial permet d'avoir des dépôts en static http : tu peux très bien héberger ton projet sur tes pages persos de free.fr par exemple.
On pourrais blablater pendant des heures, mais à notre petit niveau comme au niveau de gros projets Git et Mercurial sont équivalents sur leurs fonctionnalités et leurs performances. Choisir l'un ou l'autre est une affaire de goût, c'est comme choisir entre zsh et bash, perl et python, c++ ou java (je caricature évidemment).
Cependant je crois que tu te trompes très fort en pensant que Git va écraser la concurrence et détriment du développement de Mercurial. En fait ils vont cohabiter : le noyau Linux par exemple a un dépot Mercurial synchronisé avec le dépot Git ...
Lequel choisir alors ?
C'est pas moi qui vais répondre à la question c'est toi, selon tes critères, tes projets et tes utilisateurs !
En ce qui me concerne, tu l'auras deviné, j'ai choisi Mercurial après avoir longtemps testé les deux.
Les raisons principales ont été la simplicité (il n'y a pas photo à mon avis, depuis les docs jusqu'à l'utilisation quotidienne), et la portabilité (je travaille avec des gens qui sont sous diverses platformes dont Windows, Linux et Mac OS).
Pour les allergiques à Python, je dirais une seule chose : Python ou pas, regardez la qualité du code de Mercurial et sa petite taille comparé au mammouth qu'est déjà Git. Pour moi c'est un gage de qualité, maintenabilité et extensibilité. Après qu''il soit en Python, Eiffel ou n'importe quel language à la mode m'indiffère !
[^]Re: Idées fausses
Totalement d'accord, à part le "n'importe quel language à la mode m'indiffère" .. J'ai vécu des installs bien longues et pénibles avec darcs (en haskell). Au moins avec mercurial aucun souci c'est du bon vieux python qui tourne sur n'importe quelle version 2.x
[^]Re: Idées fausses
C'est vrai que l'aspect "installation" est important : au boulot on a une vieille Suse Linux Entreprise sur laquelle bien évidemment je n'ai pas les droits root.
Et bien j'ai installé Mercurial sur mon compte en local très facilement sans aucune dépendance à gérer et grace à la "per user installation" : http://www.selenic.com/mercurial/wiki/index.cgi/UnixInstall#(...)
Un vrai régal !
[^]Re: Idées fausses
je rajouterai que si on bosse sur un projet qui est "multi-plateforme", le choix d'un DCSM est crucial, et cela l'a été pour Mozilla. Et Mercurial l'a emporté sur GIT pour ce critère notamment chez Mozilla, parce qu'il était bien supporté sur mac et windows (puisqu'il y a beaucoup de contributeurs sur ces plateformes, et pas seulement sur linux)
Autre chose, la documentation et la simplicité : c'est un point aussi important. les DCSM ayant une logique pas forcément simple à comprendre (surtout si on a beaucoup utilisé CVS ou subversion), il faut que la doc soit complète et pédagogique. C'est d'autant plus vrai si on veut attirer des contributeurs de tout horizons et de tout niveaux.
Sinon je rejoint chicha : non mais franchement, qu'est ce que ça peut faire pour un utilisateur que le logiciel machin soit fait en python ou C ?
[^]Re: Idées fausses
Enfin quelqu'un qui traite du sujet du journal.
De mon côté, je me suis posé la même question. Et j'ai choisi Mercurial pour les critères suivants :
- marche sous linux et windows comme un charme
- la doc est très bien foutue, prise en main instantanée de mon côté
- doc imbitable côté git
Critères subjectifs mais importants (c'est une hérésie de croire que les humains font des choix "objectifs" ) :
- j'aime bien python
- à la lecture de la doc, j'ai bien aimé la philosophie développée par les développeurs : un outil simple et compréhensible
- a contrario, j'ai pas trop aimé l'approche de Linus : je fais le coeur, démerdez-vous avec des scripts shell et perl pour que ca ressemble à un SCM
- j'ai lu plein de fois les docs sur git, je comprends toujours pas le 10e des fonctions ni de comment ça marche. J'ai lu une fois la doc sur mercurial et j'ai tout compris, à la fois sur les fonctionnalités et sur le coeur.
- une boite s'est montée autour de mercurial. Ca veut dire qu'ils ont des contraintes, genre outil bien documenté, stabilité sur plusieurs environnements, etc. Linus au contraire a dévéloppé un truc imbitable en imposant son fonctionnement à tout le kernel. Il n'a pas besoin que git soit simple à utiliser (il est plutôt pour l'élevation des barrières d'entrée sur la contribution au kernel). C'est donc les autres qui ont du se farcir le sale boulot de rendre git approchable. Cette différence d'approche rend mercurial plus convivial.
- hg c'est plus court à taper que git
Globalement, à part le truc de windows et le fait que git marche plus vite pour des projets énormes, je pense qu'ils se valent tous les deux et que donc le choix de l'un ou de l'autre est subjectif.
phil.freehackers.org