Hg ou Svn ? That is the question...
Par Laurentj le vendredi, septembre 12 2008, 12:52 - Logiciels - Lien permanent
Vu que je bosse sur le code de Mozilla, je suis bien obligé d'utiliser Mercurial. Et plus j'utilise, plus j'adore. Surtout son système de pile de patch (l'extension Mq).
Se pose à moi alors la question : pour mon projet Jelix, devrais-je remplacer totalement Subversion par Mercurial ? Ou simplement utiliser Mercurial en local avec hgsvn qui me permettrait de mettre à jour mon dépot Mercurial local à partir du dépot Subversion central ?
En fait, personnellement, je n'ai pas de souci à utiliser Mercurial, bien au contraire, il apporte beaucoup de chose. Mais c'est vis à vis des contributeurs, et surtout des contributeurs potentiels. Je trouve l'utilisation d'un système de gestion de version distribué un poil plus compliquée qu'un centralisé comme Subversion, avec des concepts pas forcément évident à appréhender, surtout quand on est habitué à Subversion ou CVS. En clair, j'ai peur qu'imposer l'utilisation de Mercurial fasse peur (Déjà que j'ai l'impression que l'utilisation d'un outil de versionning ne semble pas encore être la norme en entreprise et que j'ai rencontré pas mal de développeurs web qui savaient à peine ce que c'était que cvs, svn...).
Mais peut-être me fais-je des idées ?
Et vous, qu'en pensez-vous ?
Commentaires
En entreprise ils utilisent des produit comme CCC harvest de CA, ou des produits de mercury ou bien encore ClearCase ou bien encore perforce. C'est juste que les outils open sources sont inconnus.
Etant donné que je t'avais posé la question, je suis archi pour. Tous mes projets persos sont sur bzr ou hg. Que openwechange et jelix qui sont en svn.
Avec une doc "light" de mercurial sur le site de jelix (avec le travailler avec les sources), les gens s'en sortiront.
À mon avis la question doit être : est-ce que c'est nécessaire et meilleur ?
Si oui, alors ça vaut le coup d'implémenter, même si certains risquent d'en être refroidis :)
Je suis aussi a fond pour l'utilisation de mercurial que j'utilise déjà pour mes projets. Maintenant il est peut-être possible de faire une transition en douceur avec 2 dépôts synchronisés mercurial et subversion et des hooks de partout. Mais ne sais pas si c'est une solution qui fonctionne en vrai, jamais essayé...
Ou bien imposer un workflow "svn-like" durant un temps, pour faciliter la transition...ça se fait facilement pour bzr, mais pour hg je ne sais pas. Quelqu'un a peut-être la réponse ?
L'avantage de SVN, c'est qu'il a Trac. Y a t'il des projets similaire à Trac pour Mercurial ?
@eldarion : je ne vois pas ce que tu veux dire par un workflow svn-like. Il y a des outils pour travailler avec Mercurial sur des dépôt svn (comme hgsvn)..
@Romain : il me semble qu'il y a un plugin mercurial pour Trac. Mais de toute façon, à moyen terme, y aura plus de trac :-)
@Laurent: c'est une question qui agite beaucoup de monde en ce moment. Amusant: il y a seulement quelques mois bien peu de gens avaient entendus parler de DVCS, et aujourd'hui de nombreux projets basculent.
La réponse dépend du profil des contributeurs Jelix: faut-il être geek, auquel cas la migration sera indolore, ou y a-t-il des parties où des non-geeks peuvent contribuer (traductions par exemple) ?
De toute façon c'est une question d'outils et de pédagogie. Si des outils simples d'utilisation existent, et que vous écrivez des tutoriels expliquant simplement les concepts de Mercurial et les bases des outils, ça ne devrait pas être plus compliqué à utiliser que SVN.
Et puis toujours prévoir une alternative manuelle, c'est à dire permettre de télécharger juste le source et être prêt à intégrer des patchs qui ne remontent pas par "la voie normale"
@Romain: Redmine supporte de nombreux VCS et DVCS.
Pourquoi pas si y a un réel intérêt et surtout s'il n'y a pas un ajout de complexité qui ferait partir en courant des contributeurs éventuels. Comme le dis Clochix, si y a de la pédagogie derrière, je ne pense pas que ça peut être aussi problématique que ça.
Peut être patienter encore un peu avant de migrer.
+1 pour mercurial si cela facilite la gestion de patchs/merge qui est une horreur avec svn je trouve.
Il est possible d'imaginer un depot central hg pour les contributeurs jelix et un miroir svn pour ceux qui veulent juste suivre le trunk de près, non ?
Il est vrai qu'il restera toujours la possibilité de proposer des patchs en fichier joint d'un ticket de toutes façons. Donc personne ne risque de se retrouver bloqué pour proposer un patch. Et faire un check-in sur un repository hg n'est tout de même pas si différent d'un check-in subversion.
Et pourquoi pas GIT ? Je ne sais pas vous, mais quand j'utilise un outil, j'aime bien le maîtriser, et passer à un outil plus complexe seulement lorsque j'en ressent le besoin.
A quoi bon passer sur un DVCS alors que Jelix n'a que deux branches et quelques contributeurs ? Passer à GIT pour gérer le kernel et tous ses développeurs qui travaillent des semaines sur des branches séparées se comprend; pour un projet comme Jelix, j'ai l'impression que c'est plus de la branlette intellectuelle qu'autre chose ;)
Les DVCS ne résolvent pas mieux les conflits que les VCS, ils demandent juste à l'utilisateur d'en résoudre un peu chaque jour, plutôt que tout d'un coup pour les VCS.
ps: J'utilise GIT et SVN au taf, donc je n'ai pas d'aprioris.
Et pourquoi pas Mercurial ? Mercurial, je le maitrise, il me convient, il est porté convenablement sur toute les plateformes. Donc Mercurial.
essaye de faire des merges potables avec svn. Essaye de commiter en local avec subversion (il y a pas mal de fois où ça m'aurait servi). Essaye de faire un diff ou un log sans avoir de connectivité avec le serveur svn.. Et j'en passe et des meilleurs...
Bref, si tu ne vois pas les avantages d'un DVCS, c'est que tu sembles être passé à coté des avantages de GIT à mon avis ;-)
en théorie, oui, les resolutions de conflits ne sont pas lié au fait que ce soit centralisé ou non. Mais le fait est que SVN (on oublie CVS hein...) est COMPLÈTEMENT à la ramasse pour ce qui est des merges.
Alors que la façon dont Hg ou Git font les merges, ne necessite nullement de faire ce travail quotidien, et si on le fait, c'est simple. Encore une fois, les merges avec svn, qu'ils soient quotidiens ou pas, sont merdiques (avec plein de bugs qui plus est).
Précision :
D'une part, il y en aura d'autres pour suivre les bugs des versions 1.1.x, 1.2.x à venir... Et d'autres parts, il n'y a pas beaucoup de branches (experimentales) parce que justement, le merge avec svn est pourri... Avec un outil comme Mercurial, on sera plus libre.
J'arrive après la bataille mais tant pis.
N'étant pas développeur (je contribue occasionnellement quelques traductions), du moment que la documentation pour contribuer est claire et facilement accessible, utiliser un gestionnaire de version ou un autre n'est pas difficile. Et la différence entre un centralisé et un décentralisé n'a que peu d'importance pour des contributions occasionnelles ; d'autant plus si le fonctionnement reste un minimum centralisé (ex xorg avec git).