Malgré le hype qu’il y avait pour Git, Google a tout de même choisi Mercurial, que je ne connaissais pas vraiment. J’ai donc décidé de l’essayer.

Distribué vs centralisé

Tout d’abord, Mercurial est comme Git, dans le sens où il s’agit d’un système de contrôle de version distribué. Subversion, lui, est centralisé.

Concrètement, Subversion a son repository à un endroit (générallement sur un serveur). Chaque utilisateur va chercher les fichiers (checkout), fait ses modifications et les renvoit au serveur (commit).

Mercurial, étant distribué, fonctionne de façon légèrement différente. Lorsqu’un utilisateur va chercher les fichiers, il va en fait faire une copie entière du repository. Le scénario classique est qu’un utilisateur va chercher les fichiers sur le serveur (clone), fait ses modifications et les « commet » (commit) seulement dans son repository local. Ensuite, il peut envoyer ses changement dans le repository d’où il a pris ses fichiers (push).

Avec Mercurial, on ne fait pas un checkout et un commit. On fait une branche (clone), et on la merge (push) après avoir fait un ou des changements (commit). Ça comporte plusieurs avantages pour certains types de projets, mais je n’en parlerai pas dans cet article.

Dossier .hg vs dossiers .svn

Subversion utilise plusieurs dossiers .svn. Lorsque vous travaillez dans votre checkout, il y a un dossier .svn par dossier ou sous-dossier de votre projet. Ils ne sont (supposément) pas très nuisibles.

Par contre, j’ai souvent fait face à un problème avec ces dossiers. Un client me dit qu’il veut avoir les fichiers pour montrer à son propre client. Il veut les avoir par FTP. La méthode idéale serait simplement de lui envoyer mon dossier de travail. Par contre, mon dossier de travail est infesté de .svn! Non seulement ces fichiers n’ont pas d’affaires là, mais imaginez le temps que ça prendrait mettre tout ces petits dossier en ligne! Croyez-moi, c’est trop long.

Je pourrais supprimer les dossiers .svn de tout mon projet avec un tour de passe-passe bash:

find ./ -name ".svn" | xargs rm -Rf

Mais faire ça « détruirait » mon checkout. J’aurais besoin de faire un autre checkout avant de continuer à travailler. Je pourrais faire une copie de mon dossier et faire cette commande sur ma copie. Mais copier tous ces sous-dossiers prend parfois bien du temps!

Je pourrais aussi (la solution que j’utilisais) faire un export à partir de mon repository. Il y a quelques points tannants avec cette méthode. Premièrement, Subversion est plutôt lent pour faire un export ou un checkout. Surtout que certains projets deviennent pesant assez rapidement avec les fichiers Flash et toutes les images (les PNG 24-bits ça monte vite!). Deuxièmement, lorsque le client me demande d’avoir les fichiers, j’ai parfois fait certaines modifications que je n’ai pas encore envoyées dans le repository. Je dois donc en premier faire un commit et ensuite je peux faire le export. Troisième chose, lorsque j’ai terminé d’envoyer les fichiers à mon client, je dois supprimer le dossier que je viens de créer. Pas grand chose vous direz, mais c’est quand même une étape de plus, qui n’a pas sa place à mon avis.

Mercurial, lui, ne parsème pas ses dossiers un peu partout au travers du répertoire de travail. Il n’y a qu’un dossier .hg à la racine du repository (rappelez-vous que le dossier de travail est un repository en soit). Donc, tous les problèmes énoncés ci-haut disparaissent. Je peux directement envoyer mon répertoire de travail, en prenant la peine de désélectionner le dossier .hg (et les autres fichiers, s’il y a lieu, comme .hgignore).

Commit local

Avec Subversion, lorsqu’on fait un commit, on envoie les modifications au serveur, car c’est lui qui contient le repository. Avec Mercurial, lorsqu’on fait un commit, il n’y a aucune utilisation du réseau. Le repository est local. On peut donc faire plusieurs commit sans envoyer les modifications au repository où on a pris les fichiers. Lorsqu’on est prêt, on push les commit qu’on a fait.

Vitesse

Je ne peux pas garantir que Mercurial est plus rapide que Subversion, mais je dois avouer que je trouve l’expérience beaucoup plus fluide avec Mercurial qu’avec Subversion.

Facilité

J’avais jeté un oeil rapidement à Git il y a quelque temps, mais je ne m’y était pas attardé. La première impression que j’avais eu était que ça semblait compliqué. Comme les projets sur lesquels je travaille ne profitent pas vraiment du fait que ce soit extrêmement facile de brancher-merger avec les systèmes distribués, j’avais simplement laissé Git de côté. Je n’étais peut-être pas dû pour changer de système à ce moment…

Par contre, lorsque j’ai essayé (et maintenant adopté) Mercurial, j’ai eu une toute autre impression! Il est facile à comprendre et, à mon avis, bien conçu. La courbe d’apprentissage est très légère.

Ajout de fichiers

Avec Subversion, il faut ajouter les fichiers un par un. Encore une fois, ce serait sûrement possible de faire un tour de passe-passe avec grep, mais ça serait plutôt tannant. Si on crée 8 nouveau fichiers, il faut ajouter les 8 fichiers un après l’autre.

Avec Mercurial, la même commande (add) ajoute tous les nouveaux fichiers. Pas de perte de temps. Si on veut ne pas ajouter certains fichiers (exemple: ceux se terminant avec ~), il suffit de se faire un fichier .hgignore dans la racine de notre projet, et le tour est joué.

Hébergement

Premièrement, de la façon dont est conçu Mercurial, il est beaucoup plus facile de ne simplement pas utiliser d’hébergeur. On se fait un repository avec hg init mon_projet et on peut déjà commencer à travailler dans le dossier! Pas besoin de faire un checkout et de travailler dans le dossier du checkout.

Ensuite, comme Subversion, on peut simplement fonctionner par SSH (si vous avez accès à un autre ordinateur/serveur par SSH). hg push ssh://user@example.com/chemin/vers/repo. C’est simple et rapide.

Vous pouvez aussi configurer Mercurial pour fonctionner par HTTP si votre projet a un peu d’envergure. Par contre, ce n’est probablement pas la solution idéale si vous faites parti d’une petite compagnie qui travaille sur plusieurs petits projets.

Sinon, il y a un certain nombre d’hébergeur. Le plus gros est probablement bitbucket. Ils offrent l’hébergement gratuit pour les projets open source, mais aussi de l’hébergement privé. Ils sont un peu le GitHub de Mercurial.

Essayez-le!

Tout ça pour vous dire que ça vaut la peine de l’essayer! Si vous avez peur du command-line, je crois qu’il y a même des GUI plutôt bien faits pour Windows, OS X et Linux.

Avec tous les autres, il y a toujours plusieurs restrictions ou bugs. Mais c’est une chose du passé avec DD_belatedPNG. Okay, le nom est affreux (et leur page aussi), mais je vous jure, essayez-le! Le seul petit bug que j’ai pu y trouver, c’est que si le PNG en background-image est plus grand que l’élément concerné et que ça dépasse du viewport du navigateur, il va y avoir des barres de défilement qui vont apparaître.