En plein dans le Mercure
Par Laurentj le lundi, juillet 20 2009, 20:26 - Logiciels - Lien permanent
En ce moment, je m'amuse pas mal avec Mercurial.
Chez Zoomorama, parce que Subversion devenait limitant pour nous, nous avons décidé de migrer vers Mercurial. On a pas mal recherché et discuté des différents avantages et inconvénients entre git et mercurial, et hg nous semble plus approprié pour nos besoins.
- Mercurial nous semble plus propre d'un point de vue des commandes (Il n'y a pas 144 scripts différents avec des dépendances dans tout les sens comme dans Git) et il est presque aussi simple à utiliser que subversion. Cela nous fera gagner du temps pour s'approprier l'outil.
- Il y a une très bonne documentation (bien que celle de Git semble s'améliorer), entre autre ce guide
- Et surtout il a un bon support sur toutes les plateformes, ce qui est important pour nous puisqu'on fait, entre autres choses, des applis multi plateformes basées sur Mozilla.
- On utilise Gecko, en le modifiant, et Gecko étant sous Mercurial, ça ne nous fait pas apprendre un nième outils.
Au niveau fonctionnalités, Git et Mercurial se valent je trouve, surtout dans les fonctionnalités de base. Mercurial a beaucoup progressé et comblé son relatif retard ces derniers temps. Et vu qu'on ne va pas forcément utiliser les fonctionnalités super avancées de ces outils ce n'est pas sur ce point qu'on a pu les départager (quoique, j'apprecie beaucoup l'extension mq de Mercurial)... D'un point de vue performance, on n'a pas des projets de plusieurs dizaines de millions de lignes de code, aussi je ne pense pas que Mercurial va nous pénaliser (bien qu'il parait qu'il est plus lent que Git sur certaines opérations).
Le seul inconvénient qu'on lui trouve : le site officiel est moche par rapport à celui de git :-), mais heureusement, il y a un nouveau site plus propre : http://hg-scm.org/.
Un bon comparatif (sans troll et assez objectif je trouve) qui a fini par nous convaincre : Git vs Mercurial.
Et puis, du coté de mes projets perso, je suis en train aussi de passer aussi à Mercurial. Pour Jelix, je viens de monter http://hg.jelix.org. Je dois encore configurer les droits d'accés pour le push via ssh (c'est moins classe à configurer que pour subversion [1]) et quelques autres broutilles (comme modifier les cron des builders de nightlies). Je vais enfin pouvoir commiter dans le train !
À propos de gestionnaire de sources, le projet PHP vient de changer lui aussi de système. Ils ont enfin délaissé CVS pour utiliser Subversion. Je m'étonne toutefois qu'ils ne se soient pas orienté vers Git, Mercurial ou un autre système décentralisé. Surtout que je n'arrive pas à mettre la main sur leurs arguments en faveur de Subversion par rapport à Git/Mercurial.
Notes
[1] en fait non, une fois compris le truc, c'est bien plus puissant, en utilisant http://hg.opensource.lshift.net/mercurial-server/ et je viens de terminer sa configuration :-)
Commentaires
Subversion, ça c'est du choix d'avenir...
J'ai l'impression que l'ouverture de PHP est toujours aussi relative. Je me rappel d'un billet dans lequel tu parlais de la difficulté à proposer des patchs.
Décidément, il semble que nous soyons souvent en résonnance. Il y avait quelques mois, j'avais quitté Eclipse pour Komodo quelques semaines avant que tu ne rédiges un article à ce sujet. Et je travaille avec Mercurial depuis maintenant 2 mois. Enfin, c'est à titre perso, car professionnellement, je pense que nous ne sommes pas prêts de migrer.
Pour tester à fond et essayer autre chose que PHP (désolé je ne connais que symfony, car quand nous avons commencé nos dev, je ne connaissais pas Jelix), je me suis lancé un petit défi, à savoir développer un petit Trac-like (enfin en mieux !) avec Django et Mercurial. J'ai été vraiment très agréablement surpris par la facilité avec laquelle j'ai pu intégrer les deux (authentification de Mercurial au travers de django par ex)
Question performances, j'ai récupéré quelques gros dépôts comme Mozilla ou django (qui est en fait un miroir du SVN). Sur un MacBook 2.4 GHz/2Go de RAM/HDD 5400tr/min, l'accès aux dépôts ne nécessite que 90 ms (pour lire l'historique par ex, afficher la source d'un fichier, etc.) Seule la traversée des dépôts pour afficher l'arborescence prend plus de temps sur les gros dépôts, environ 900ms pour Mozilla 1.9.1 (60000 fichiers, 30000 révisions, 700Mo) et 1500ms pour django (42000 fichiers, 25000 révisions, 350Mo) Apparemment, la conversion depuis SVN à un coût.
Pour ceux qui voudraient jeter un coup d'œil, c'est à cette adresse:
http://bitbucket.org/nautilebleu/dj...
(oui je sais, je devrais utiliser django_hg pour mes propres projets, en fait j'y travaille, j'espère pouvoir profiter des vacances pour terminer la charte et terminer les fonctions qui manquent.)
Un des arguments qui m'a fait choisir Mercurial, c'est sa simplicité et la possibilité d'accéder directement au code depuis un autre projet en Python.
Et pouvoir commiter dans le train, je confirme, c'est vraiment pratique !
J'ai été également surpris que PHP choisisse Subversion. Quitte à migrer, sans doute aurais-je choisi un DCVS.
Je me permet de mentionner un article que je viens d'écrire sur l'extension hgsubversion qui permet d'utiliser mercurial comme client subversion. http://bit.ly/154FaC
Un inconvénient que j'ai relevé de Mercurial par rapport à Git est la souplesse de création de branches.
Il est extrêmement facile de revenir en arrière et de commiter un nouveau changeset et ainsi créer une nouvelle branche (qui n'aura finalement pas de noms). Le fait d'avoir une nouvelle branche nom nommée rendra les push/pull plus compliqués et introduit une complexité que pas mal de développeurs n'ont pas envie d'avoir.
À l'opposé, Git oblige à nommer toutes les branches qui sont créées et refuse catégoriquement de commiter un changeset sur une version qui n'ai pas à jour, ce qui est finalement plus proche du modèle de Subversion et déroutera moins de personnes.
Mais je suis d'accord que les commandes de Git sont encore trop loin de Subversuission pour le développeur lambda. L'avenir nous dira si Git arrivera à imposer son vocabulaire avant que Mercurial n'implémente une gestion plus rigide des branches nommées.
Moi je voudrais bien qu'on m'explique l'intérêt de migrer vers un système de gestion de version décentralisée quand on utilise Subversion.
J'ai pas cherché longtemps, mais je n'ai trouvé que le commit dans le train et le fait que chacun puisse faire ce qu'il veut dans son coin vu qu'il y a du super-merge inside.
C'est tout ?
J'aime bien les solutions dernier cri qui font travailler mieux, mais là j'ai un doute sur cette mode du DVC. Une migration c'est jamais gratuit, j'aimerais bien savoir ce qu'il y a mettre dans la balance pour que tant de monde s'y intéresse ?
@BenLeTibetain
Je me posais un peu les mêmes questions jusqu'à ce que je me mette à Mercurial. Au-delà des exemples cités qui ne concerne pas tout le monde, je dirais que les DCVS ont pour moi l'avantage d'inciter à l'expérimentation sans que l'on tombe dans le "cowboy development": comme le dépôt est local, je peux tester des trucs, créer des branches, committer, revenir en arrière, etc. sans impacter forcément toute l'équipe de développement. Avec Subversion, soit les développements auraient été committer dans le trunk, soit il aurait fallu demander à l'administrateur de créer une branche dédiée, ce qui n'est pas toujours simple à justifier et à obtenir.
En outre, comme tous les dépôts locaux sont des forks, les DCVS ont été obligés de se doter d'outils de merge plus puissants que SVN.
Enfin, avec SVN, il me ne semble pas simple de dépasser le workflow par défaut, tandis que les DCVS permettent d'imaginer des workflows adaptées, comme par exemple les développeurs qui committent vers les dépôts de sous-chefs de projets qui valident chacun une partie des modifications, avant de committer eux-même vers le dépôt du chef de projet qui merge l'ensemble et le remet à disposition de l'ensemble de l'équipe de développement.
Goulwen :
> En outre, comme tous les dépôts locaux sont des forks, les DCVS
> ont été obligés de se doter d'outils de merge plus puissants que
> SVN.
Justement c'est un peu ce qui me fait peur, c'est de me retrouver à traiter manuellement bcp de conflits pendant les merge. J'ai peur que le temps gagné en étant plus souple sur la gestion des dépôts et des commits soit annulé par l'étape du merge. J'imagine bien que le merge est plus puissant sur ces outils de gestion décentralisée, mais jusqu'à quel point ? Qu'en est-il dans la réalité ?
@benletibétin : ben c'est simple, vu la puissance des merges, chacun peut maintenir sa propre branche dans son coin, avec ses propres patchs. Avec subversion, les merges, c'est juste pas possible, parce que ça ne marche juste pas (en tout cas, les fois où j'ai essayé, ça m'a explosé ma copie local, obligé de tout refaire etc). Donc oui, c'est sûr, il va y avoir plus de conflit à gérer, puisque maintenant on peut faire des branches comme on veut ;-) Mais quand c'est couplé avec des bons outils de merge comme kdiff3, ce n'est pas un souci au final. Et puis pour éviter trop de conflits, suffit de faire des merges régulièrement.
Et puis le fait de ne pas dépendre d'un serveur, c'est vachement utile. Un exemple : en ce moment, je suis en train d'améliorer un truc qui a été fait par une autre personne. Malheureusement, il n'y a pas de depot officiel quelque part de ce projet, son auteur travaillant seul. Pour lui proposer des patchs, c'est simple : je me suis créer un depot en local. Pas besoin de configurer un serveur : j'ai téléchargé les sources disponibles, fait un hg init sur le répertoire, et voilà, mes modifs vont être historisé, ce qui me permettra de créer des patchs facilement. Et si je veux rendre publique tout ça, je ferais un simple hg clone monrepertoire vers un serveur hg...
et sinon comme Goulwen, pour les contributeurs de jelix, si ils ont à proposer un patch : hg clone du dépôt officiel, et ils commitent toutes leurs modifs en local. Ils peuvent historiser leur travail avant de proposer un patch (ce qui est très agréable quand on travail sur un gros patch), ce qu'ils ne pouvaient faire avec le depot subversion (sauf à utiliser des outils dans tout les sens pour synchroniser leur serveur local avec le distant et cie....)
En clair, un contributeur est beaucoup plus libre de travailler comme il veut avec un DVCS qu'avec un VCS, tellement cela apporte de la souplesse.
Oulla ! il faut que je trouve le temps de mettre a jour mon dépot Jelix pour passer a Mercurial.
Quelqu'un connait un client hg sous windows ?
@bibo : tortoiseHg
Et pour l'avoir essayer il est bien foutu.
Un peut moins bien fini que tortoiseSvn.
Ok en effet, je veux bien croire que ça soit plus efficace.
Il va falloir que j'étudie ça de plus prêt, en particulier au niveau migration.
Y a-t-il moyen d'importer un dépôt SVN plutôt que de faire un init/clone sur une copie de travail ?
Trac fonctionne-t-il bien avec HG ?
Pour l'import : hg convert url_de_tondepotsvn tout simplement. voir http://mercurial.selenic.com/wiki/C...
et sinon, y a un plugin pour trac (pas testé). mais je doute que le plugin soit à la hauteur du browser hgweb.
Le serveur web intégré permet de parcourir le projet à ses différentes révisions, mais il ne comprend pas de système de ticket. Ce n'est donc pas totalement l'équivalent de Trac.
En outre, l'installation avec Apache n'est pas simple je trouve.
Il me semble qu'InDefero [1] permet d'afficher les dépôts Mercurial en plus de SVN.
Sinon le github de Mercurial est bitbucket [2]. C'est très d'utilisation, gratuit pour les projets open-source, même si ça veut dire recentraliser. Google Code et SourceForge supportent aussi Mercurial.
Et sinon, pour avoir un outil à installer chez soi, je me permet de rappeler l'existence de mon projet django_hg (voir mon précédent commentaire): il n'est pas encore fini, mais j'ai pas mal avancé depuis le dernier commit, j'espère pouvoir mettre ça en ligne la semaine prochaine.
[1] http://www.indefero.net/
[2] http://bitbucket.org/
>Le serveur web intégré permet de parcourir le projet à ses différentes révisions, mais il ne comprend pas de système de ticket. Ce n'est donc pas totalement l'équivalent de Trac.
Je parlais de la partie "browser de source" de trac. HGweb est bien mieux que celui de trac.
>l'installation avec Apache n'est pas simple je trouve
bof, pas forcément plus compliqué que pour svn ou autre. Après c'est sûr, faut connaître apache ;-)
>C'est très d'utilisation, gratuit pour les projets open-source, même si ça veut dire recentraliser
Tu connais des projets où il n'y a pas un quelconque dépôt "officiel" quelque part ? "décentraliser" ne veut pas dire ne plus avoir de depot central "officiel".