Si vous connaissez déjà subversion , Mercurial (Hg) va être déroutant .

Quand mes programmeurs ont décidé de passer de Subversion vers Mercurial, j’étais perdu.

D’abord j’ai invoqué toutes les raisons stupides pourquoi nous ne devons pas basculer . « Nous devons gardé le dépôt (repository) sur le serveur central, pour qu’il soit sûr ». Vous savez quoi ? J’avais tort. Dans Mercurial, tous les développeurs ont une copie entière de leur dépôt sur leur disque dur. En fait , c’est plus sûr. Presque chaque équipe Mercurial utilise un dépôt centralisé, aussi, dont on peut faire une sauvegarde compulsive.

« Le problème avec un contrôle de version décentralisé, c’est que c’est trop facile de faire des branches » Je l’ai dit  » les branches créent toujours des problèmes ». Cette fois, j’avais tort. Créer une branche dans Subversion cause des problèmes parce que Subversion ne stocke pas assez d’informations pour que la fusion marche. Dans Mercurial , fusionner est indolore et facile, et du coup créer une branche est récurrent et sans peine.

Alors j’ai dit « Bien, je vais l’utiliser mais n’attendez pas de moi que je comprenne tout ». Et j’ai demandé à Jakob de me faire une antisèche sut toutes les commandes que je fais normalement dans Subversion, leur équivalent dans Mercurial.

Maintenant, je peux montrer cette antisèche, mais je ne vais pas le faire car ça m’a perturbé les neurones pendant des mois.

Il se trouve que si vous utilisez Subversion , votre cerveau est … comment dire poliment ? Lobotimisé . Non , c’est pas poli. Vous avez besoin d’une ré-éducation . J’ai galéré pendant six mois en pensant que Mercurial était plus compliqué que Subversion, mais seulement parce que je n’avais pas bien compris comment ça marche, et une fois compris – Ω – en fait c’est tout simple.

Donc j’ai écrit ce tutorial pour vous, dans lequel j’ai pris soin de ne pas expliquer dans les termes Subversion, car il y a déjà assez de noeuds dans les cerveaux. Au lieu de ça , pour ceux qui viennent de Subversion, j’ai consacré un chapitre au début qui va tenter réparer les dégâts autant que possible pour vous appreniez Mercurial en partant sur une bonne base.

Si vous n’avez jamais utiliser Subversion, vous pouvez passer au chapitre suivant sans rien perdre.

Prêt? Ok commençons par un quiz

Question 1. Ecrivez vous du code propre et parfait la première fois ?

Vous avez répondu « Oui » à la question 1, alors vous êtes un menteur . Perdu. Reprenez le test.
Le code nouveau est bogué . Ca prend du temps avant que ça fonctionne correctement. Entre temps , ça cause un trauma aux autres développeurs de l’équipe. Maintenant voici comment Subversion fonctionne :

quand le code est commit , tout le monde le récupère
Comme tout nouveau code comporte des erreurs , le choix entre :
faire un commit de code boggué et aliéner tout le monde ou
éviter de faire un commit jusqu’à ce soit correct

Subversion et les autres logiciels de gestion de versions centralisé donnent toujours ce dilemme. Soit le dépôt est plein de bugs avec le nouveau code , or le nouveau code n’est pas dans le dépôt. En tant qu’utilisateur de subversion , nous  sommes telment habitués à ce dilemme.

Les utilisateurs Subversion n’ajoutent souvent rien pendant des jours voire semaines. Les nouveaux à Subversion sont terrifiés de rajouter leurs modifications , de peur de casser le ‘build’, ou d’énerver Mike, le senior. Une fois Mike s’est mis dans une rage sur un ajout qui a cassé le build qu’il est rentré dans le bureau d’un stagiaire et lui a crié: « C’est ton dernier jour ! » (Ce n’était pas mais le pauvre stagiaire a une peur bleue )

Quand j’étais  à Siemens , nous utilisions Clearcase qui est un outil de gestion de configuration centralisé. J’ai demandé l’aide d’une collègue senior. Sans voir un défaut dans l’outil, elle m’a expliqué comment procéder : copier les fichiers en cours , faire d’autres copies intermédiaires jusqu’à le « build » passe. Quand tout on est bon, on peut ajouter.

Les gens écrivent du code pendant des jours et  semaines sans avoir le bénéfice d’un contrôle de version et vont chercher l’aide d’un senior pour ajouter. A sert un outil de contrôle de version si on peut pas l’utiliser ?

Voici une illustration de la vie sous Subversion :

Dans Mercurial , chaque développeur a son propre dépôt  sur son poste de travail.

Donc vous pouvez faire un commit du code dans votre dépôt local, et d’avoir tous les bénéfices de contrôle de version n’importe quand. Chaque fois que vous arrivez à une étape, votre code s’améliore, vous pouvez faire un commit.

Une fois que c’est solide, et vous voulez laisser les autres utiliser votre code, vous exportez (push) de votre dépôt vers le dépôt central où tout le monde récupère (pull) , et ils voient votre code . Quand c’est prêt.

Mercurial sépare l’acte de faire un commit du nouveau code de le partager avec tout le monde.

Vous pouvez faire un commit (hg com) sans que personne ne reçoivent vos changements. Quand vous pensez que les modifications sont stables et tout est bon, vous pouvez exporter ( hg push ) dans le dépôt central.

Publicités