Home > Informatique > Subversion vs Mercurial

Subversion vs Mercurial

janvier 19th, 2011 Leave a comment Go to comments

La plupart des développeurs à l’heure actuelle utilisent un gestionnaire de versions pour le code de leur application. C’est indispensable lors d’un travail en équipe mais cela peut être aussi fort intéressant même si on est seul sur un projet, car on dispose d’un historique de toutes les modifications effectuées .

Reste à savoir quel gestionnaire de version utiliser : personnellement j’ai commencé par CVS puis sa version améliorée Subversion. Il y a quelques temps lors du démarrage du projet Domogik, mon collègue m’a proposé d’utiliser Mercurial. Je ne connaissais pas spécialement et j’ai dit “Ok pourquoi pas”. Il m’a vaguement expliqué les différences en me précisant que Mercurial était un gestionnaire de versions décentralisé. Cela n’a pas fait “tilt” chez moi et j’ai à peine relevé la remarque. Lorsqu’on a commencé à travailler, en bon informaticien, je n’ai pas pris le temps de lire la documentation de Mercurial et je me suis dit : “Bon à part la syntaxe des commandes qui change ça reste un gestionnaire de versions”.

Et là grave erreur, j’ai utilisé pendant des mois Mercurial comme j’aurais fait avec Subversion. Du coup j’ai fréquemment pesté envers Mercurial, avec toute la mauvaise foi qui s’impose, avançant des arguments tels que “Mercurial c’est beaucoup trop compliqué pour notre projet” etc. Je dis grave erreur, car par hasard un autre collègue m’a donné le lien vers un excellent tutoriel qui explique les différences fondamentales entre Subversion et Mercurial. Là je me suis dit que j’avais perdu pas mal de temps en sous-exploitant la souplesse offerte par Mercurial. En voici un (très gros) résumé :

  • Mercurial est effectivement décentralisé, ainsi chaque développeur possède son propre dépôt (repository). Ainsi vous pouvez effectuer des commits locaux sans affecter le dépôt central tout en bénéficiant d’un historique de vos modifications.
  • Mercurial utilise la notion de changeset plutôt que de revision. Cela signifie, en gros, qu’il mémorise l’historique des changements qui ont été appliqués pour passer d’une version à l’autre. Subversion lui mémorise les versions de chaque fichier.
  • La notion de fusion (merge) est parfaitement gérée par Mercurial, et je dirais qu’il s’agit même d’une opération qu’on est amené à effectuer assez fréquemment. Si vous êtes plusieurs développeurs qui travaillent sur une même version et que vous effectuez régulièrement des commits sans les publier sur le dépôt central, alors lorsque vous souhaiterez récupérer les mises à jour de vos collègues, un merge sera nécessaire, même si vous n’avez pas travaillé sur les mêmes fichiers (je sais,  lorsqu’on vient du monde de Subversion cela peut paraître étrange, mais vous comprendrez le pourquoi du comment si vous suivez le tutoriel dont je vous parle à la fin). Notons qu’avec Subversion la notion de merge fait souvent peur et doit être appliquée très prudemment, avec Mercurial il y a rarement des soucis.

Bon les différences que j’expose ci-dessus peuvent vous paraître énigmatiques si vous ne connaissez pas Mercurial, mais elles sont fondamentales. Pour ceux qui sont confrontés à la gestion de versions (et qui lisent la langue anglaise), je vous recommande très chaudement cet excellent tutoriel. Après l’avoir lu, alors que j’étais initialement réticent à Mercurial, j’ai été définitivement convaincu sur la supériorité de Mercurial. Il n’est pas plus compliqué à utiliser que Subversion et offre à mon sens beaucoup plus de possibilités.

Bonne gestion de versions !

Références :

Categories: Informatique Tags: .: mercurial .: subversion
  1. janvier 19th, 2011 at 22:42 | #1

    Merci pour l’article et les liens, je viens aussi de passer à Mercurial pour participer à un projet libre. Utilisant Subversion au boulot, je ne comprenais pas, au début, pourquoi mes commits n’étaient pas publié directement sur le repository distant.

  2. 3po
    janvier 20th, 2011 at 02:41 | #2

    Personnellement, je préfère Git à Mercurial.

  3. Marco
    janvier 20th, 2011 at 07:49 | #3

    Je ne connais que très peu GIT, tu peux développer ?

  4. janvier 21st, 2011 at 19:52 | #4

    Salut,

    Je suis passé aux gestionnaires de version décentralisés il y a quelques années, avec bazaar. Et il faut bien avouer que ça permet une souplesse et une liberté incomparable avec subversion ou CVS. C’est peut être d’ailleurs la raison pour laquelle ces deux VCS sont toujours si utilisés en entreprise.

    Je ne connais pas mercurial, mais j’ai eu l’opportunité de me frotter à git et bazaar, et je conseillerais à ceux qui hésitent entre les deux de choisir bazaar. Bien qu’il ait moins de « features » que git, son utilisation est bien mieux pensée et on n’a pas besoin de fouiller 3h dans le manuel pour réussir un bête « pull » (l’équivalent d’un update dans subversion).

  5. 3po
    janvier 26th, 2011 at 15:17 | #5

    Et bien, il n’y a pas énormément de différences entre les deux mais c’est surtout l’impression générale que j’en ai.

    J’ai pas beaucoup d’arguments non « trollesques » à te soumettre à part peut être le concept de « staging area/index » qui n’existe pas dans mercurial que j’utilise assez souvent (qui permet de sélectionner précisément ce qui doit être commité ou pas).

    Il y a aussi la commande « git stash » que je ne retrouve pas dans mercurial mais j’ai peut-être mal cherché (qui permet de faire une sauvegarde de tous les changements courants sur une pile et de revenir à la révision courante en un instant).

    L’aide est aussi plus fournie je trouve et le site d’hébergement Github est bien pratique pour son coté très social.

    Mercurial a quelques avantages aussi mais moins importants pour moi, bref il faut utiliser un peu des deux et faire son choix. 🙂

  6. 3po
    janvier 26th, 2011 at 15:53 | #6

    (j’ai trouvé pour « git stash » c’est une extension appelée « hg shelve » apparemment, j’ai surement dû rater d’autres extensions utiles)

  7. shadoo
    mars 13th, 2013 at 16:54 | #7

    Il n’y a pas une différence fondamentale entre Git et Mercurial, dire « préférer » git à mercurial sans argument, c’est effectivement un peu trollesque mais concrètement git est très répandu, donc on peut facilement trouver des sources afin de l’utiliser notamment avec l’avènement de github qui a un peu propager tout ce mouvement et puis git ça vient de linus torvalds autre que le père de linux donc déjà c’est pas rien.

    La différence pour le moment que j’ai constaté entre git et mercurial, c’est que :
    – Mercurial est plus simple à utiliser que git déjà, surtout si on vient de svn à la base (comme beaucoup)
    – Le fait que mercurial possède moins de fonctionnalités de bases fait aussi que cela soit plus simple à comprendre, il est possible d’ajouter des extensions.
    – mercurial possède à priori plus des commandes intuitive et logique en rapport à git, d’après pas mal de retour de développeur

    je n’ai pas pu hélas utiliser git plus en profondeur (ni mercurial pour le moment non plus) par manque de temps hélas. j’espère qu’il y aura un schema montrant la différence entre git et mercurial par exemple voir si il y a vraiment des différences mais grossomodo on peut utiliser l’un où l’autre cela n’a pas beaucoup d’importance.

    Aujourd’hui j’oriente plus les entreprises chez qui je vais bosser vers mercurial car je le connais plus (si on peut dire) que git, même si je connais suffisamment git pour l’installer et l’utiliser mais je pars sur le point qu’il est plus rapide d’apprentissage que git donc je joue surtout sur cela et mercurial tant à être de plus en plus utilisé.

    même si les plus utilisé encore à l’heure actuel en entreprise sont svn et git.

  1. No trackbacks yet.