Subversion ré-éducation

Traduction de  http://hginit.com/00.html
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 quizz

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 committé , 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é mènent 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.

Une autre grande différence de conception

Vous savez que chaque rue a un nom ?

Bien ce n’est pas le cas au Japon. Ils donnent des numéros aux blocs (番地, banshi) entre les rues, et seulement les rues importantes portent un nom.

Il y a une différence similaire entre Subversion et Mercurial.

Subversion raisonne en terme de révisions. Une révision est la représentation d’un système de fichiers à un point dans l’histoire.
Dans Mercurial , on pense en changeset . Un changeset est une liste des modifications entre une révision  et la révision suivante.

Six, la moitié d’une douzaine: quelle est la différence ?

La voici. Imaginez que vous et moi ,nous travaillons sur du code et nous créons une branche, nous avons chacun une copie locale nous faisons plein de modifications de ce code séparément, donc il a divergé.

Quand on fusionne, Subversion regarde aux deux révisions – mon code modifié, et votre code modifié- et il essaye de deviner comment le regrouper ensemble  dans un gros bordel. Ca produit généralement des conflits de modification qui ne sont pas réellement des vrais conflits, simplement des endroits où Subversion a échoué de deviner ce qu’on a fait.

Au contraire , pendant que nous travaillions séparément dans Mercurial, Mercurial conserver une série de changesets. Et quand on fusionne le tout , Mercurial a plus d’information: il sait ce que chacun de nous a modifié et peut re-appliquer ces modifications, plutôt que de regarder au résultat final et essayer de deviner comment faire.

Par exemple si je change un peu une fonction, et la déplace ailleurs, Subversion ne se souvient pas de ces étapes, donc au moment de fusionner, il va penser qu’une nouvelle fonction est apparue de nulle part. Alors que Mercurial va se rappeler de ces choses séparément : fonction changée, fonction déplacée. Si vous avez modifié cette fonction par morceau, il y a plus de chance que Mercurial fusionne correctement nos modifications.

Comme Mercurial raisonne en changeset, on peut obtenir des choses intéressantes. Vous pouvez les exporter à un ami de l’équipe, au lieu d’exporter vers le dépôt central et d’en affecter toute l’équipe.

Si tout ça est déroutant, ne vous en faites pas – à la fin du tutorial vous allez y voir plus clair. Ce qui est important à retenir : Mercurial pense en terme « changesets » au lieu de « révisions » la fusion de code est meilleur que sous Subversion .

Ca veut dire qu’on peut faire des branches quand on le souhaite parce que la fusion se fera sans peine.

Vous voulez entendre une blague ? Chaque équipe Subversion que j’ai rencontré m’a raconté des variations de la même histoire. Cette histoire est si répandu que je la nomme   » Histoire Subversion numéro 1″. L’histoire : à un moment, ils ont créé une branche, pour que la version en cours de livraison aux clients soit isolée de la version que les développeurs  bidouillent. Chaque équipe m’a raconté qu’ils l’ont fait et ça marche jusqu’à qu’ils fusionnent le code, et c’est devenu un cauchemar. Ce qui devait prendre 5 minutes s’est terminé avec six développeurs autour d’un poste pendant deux semaines essayant de ré-appliquer chaque résolution de bug du build stable au build de développement. Presque chaque équipe s’est juré « plus jamais » de branches. Maintenant chaque nouvelle fonctionnalité est un gros bloc de #ifdef. Comme ça ils peuvent travailler sur un seul tronc commun, pendant que les clients ne voient jamais le nouveau code jusqu’à ce qu’il soit débogué, franchement c’est ridicule.

Garder le code stable de celui en  développement est justement ce que doit vous laisser faire un outil de contrôle de version

Quand vous passerez à Mercurial, vous n’allez peut-être pas le remarquer, mais faut pas avoir peur de créer des branches.

Ca veut dire que vous pouvez avoir des dépôts par équipe, où une petite équipe collaborent sur une nouvelle fonctionnalité, quand ils ont fini, ils le fusionnent dans le dépôt principal de développement, et ça marche !

Ca veut dire que vous pouvez expérimenter dans des dépôts séparés, si ils fonctionnent, vous les fusionner dans le dépôt central, sinon vous pouvez les abandonner. Et ça marche !

Une dernière différence de conception

La dernière différence de conception entre Mercurial et Subversion n’est pas si importante . Vous n’allez sans doute pas la remarquer , la voici :

Subversion est un contrôle de révision pour fichiers , mais dans Mercurial, le contrôle de révision s’applique toujours dans un dossier ou sous-dossier.

Pour voir ça, dans Subversion, si vous allez dans un sous-dossier et faites un commit des modifications, il va seulement faire un commit des modifications dans ce sous-dossier et ses dossiers contenus. Potentiellement vous pouvez avoir oublier d’autres fichiers dans d’autres sous-dossiers. Tandis que sous Mercurial,, toutes les commandes s’appliquent à l’arborescence
entière. Si votre dépôt se trouve dans c:\code, la commande  hg commit, que vous soyez dans c:\code ou dans n’importe quel sous-dossier , ça aura le même effet.

Rien de révolutionnaire, mais si vous êtes habitué à travailler dans un dépôt gigantesque qui gère tous les projets de l’entreprise. Ce n’est pas une façon de travailler avec Mercurial, il est recommandé d’avoir un dépôt/plusieurs petits dépôts par projet.

Et enfin…

Mercurial est meilleur que Subversion.

Il est meilleur pour collaborer avec une équipe sur de code source. Meilleur pour travailler seul sur du code source.

C’est juste mieux

Prenez mes mots , si vous comprenez comment Mercurial opère, vous travaillez de cette façon, et vous n’allez pas à l’encontre, n’essayez pas de re-appliquer comme sous le vieux Subversion mais que vous appreniez les nouvelles méthodes sous Mercurial, vous serez heureux et plein de succès.

Dans les premiers jours, vous serez tenté , je sais, d’abandonner Mercurial et retourner sous Subversion, car c’est étrange comme vivre dans un pays étranger. Vous allez remettre en questions l’outil, par exemple vous allez clamer que Mercurial prend plus d’espace disque, alors que en fait les dépôts prennent moins d’espace disque. ( ce qui est vrai !)

Et vous allez revenir à la Subversion parce que vous avez essayer de faire un branche à la Subversion, et vous êtes confus, ça ne s’est pas bien passé, parce vous auriez dû faire une branche à la Mercurial, en clonant les dépôts, non pas en faisant à la Subversion, mais en apprenant à la Mercurial, qui croyez-moi, fonctionne.

Et vou allez avoir Jacob ou son équivalent au travail, pour vous donner les « antisèches de Subversion à Mercurial » , vous allez passer trois mois Mercurial penser que hg fetch est juste l’équivalent de svn up , sans réellement savoir ce que hg fetch fait derrière. Et un jour, les choses vont mal se passer et vous allez accuser Mercurial, quand le fautif c’est vous pour ne comprendre comment Mercurial fonctionne.

Je sais que vous allez le faire parce que c’est ce que j’ai fait.

Ne faites pas la même erreur. Apprenez Mercurial, faites confiance à Mercurial, vous avancerez vers une nouvelle génération de gestion de contrôle de source. Pendant que vos concurrents sont occupés pendant une semaine à résoudre tous les conflits de fusion qu’ils ont eu quand un intégrateur a fait la mise  à jour d’une librairie, vous allez taper hg merge et dire :  » Oh c’est cool, ça marche tout simplement. » . Et Mike va se détendre et partager une glace avec les stagiaires, ce sera le printemps et la vie sera belle.

Subversion ré-éducation 2 : un autre grande différence conceptuelle

Vous savez que chaque rue a un nom ?

Bien ce n’est pas le cas au Japon. Ils donnent des numéros aux blocs (番地, banshi) entre les rues, et seulement les rues importantes portent un nom.

Il y a une différence similaire entre Subversion et Mercurial.

Subversion raisonne en terme de révisions. Une révision est la représentation d’un système de fichiers à un point dans l’histoire.
Dans Mercurial , on pense en changeset . Un changeset est une liste des modifications entre une révision  et la révision suivante.

Six, la moitié d’une douzaine: quelle est la différence ?

La voici. Imaginez que vous et moi ,nous travaillons sur du code et nous créons une branche, nous avons chacun une copie locale nous faisons plein de modifications de ce code séparément, donc il a divergé.

Quand on fusionne, Subversion regarde aux deux révisions – mon code modifié, et votre code modifié- et il essaye de deviner comment le regrouper ensemble  dans un gros bordel. Ca produit généralement des conflits de modification qui ne sont pas réellement des vrais conflits, simplement des endroits où Subversion a échoué de deviner ce qu’on a fait.

Au contraire , pendant que nous travaillions séparément dans Mercurial, Mercurial conserver une série de changesets. Et quand on fusionne le tout , Mercurial a plus d’information: il sait ce que chacun de nous a modifié et peut re-appliquer ces modifications, plutôt que de regarder au résultat final et essayer de deviner comment faire.

Par exemple si je change un peu une fonction, et la déplace ailleurs, Subversion ne se souvient pas de ces étapes, donc au moment de fusionner, il va penser qu’une nouvelle fonction est apparue de nulle part. Alors que Mercurial va se rappeler de ces choses séparément : fonction changée, fonction déplacée. Si vous avez modifié cette fonction par morceau, il y a plus de chance que Mercurial fusionne correctement nos modifications.

Comme Mercurial raisonne en changeset, on peut obtenir des choses intéressantes. Vous pouvez les exporter à un ami de l’équipe, au lieu d’exporter vers le dépôt central et d’en affecter toute l’équipe.

Si tout ça est déroutant, ne vous en faites pas – à la fin du tutorial vous allez y voir plus clair. Ce qui est important à retenir : Mercurial pense en terme « changesets » au lieu de « révisions » la fusion de code est meilleur que sous Subversion .

Ca veut dire qu’on peut faire des branches quand on le souhaite parce que la fusion se fera sans peine.

Vous voulez entendre une blague ? Chaque équipe Subversion que j’ai rencontré m’a raconté des variations de la même histoire. Cette histoire est si répandu que je la nomme   » Histoire Subversion numéro 1″. L’histoire : à un moment, ils ont créé une branche, pour que la version en cours de livraison aux clients soit isolée de la version que les développeurs  bidouillent. Chaque équipe m’a raconté qu’ils l’ont fait et ça marche jusqu’à qu’ils fusionnent le code, et c’est devenu un cauchemar. Ce qui devait prendre 5 minutes s’est terminé avec six développeurs autour d’un poste pendant deux semaines essayant de ré-appliquer chaque résolution de bug du build stable au build de développement. Presque chaque équipe s’est juré « plus jamais » de branches. Maintenant chaque nouvelle fonctionnalité est un gros bloc de #ifdef. Comme ça ils peuvent travailler sur un seul tronc commun, pendant que les clients ne voient jamais le nouveau code jusqu’à ce qu’il soit débogué, franchement c’est ridicule.

Garder le code stable de celui en  développement est justement ce que doit vous laisser faire un outil de contrôle de version

Quand vous passerez à Mercurial, vous n’allez peut-être pas le remarquer, mais faut pas avoir peur de créer des branches.

Ca veut dire que vous pouvez avoir des dépôts par équipe, où une petite équipe collaborent sur une nouvelle fonctionnalité, quand ils ont fini, ils le fusionnent dans le dépôt principal de développement, et ça marche !

Ca veut dire que vous pouvez expérimenter dans des dépôts séparés, si ils fonctionnent, vous les fusionner dans le dépôt central, sinon vous pouvez les abandonner. Et ça marche !

traduction de http://hginit.com/00.html


subversion ré-éducation 1

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.

Hg Init : un tutorial sur Mercurial

Mercurial est un controle de source distribué et une amélioration de systèmes plus anciens comme Subversion. Ce tutorial facile d’accès découpé en six parties vous enseignent les concepts clés.

Ce tutorial est traduit de hginit.com

Hello world!

Welcome to WordPress.com. After you read this, you should delete and write your own post, with a new title above. Or hit Add New on the left (of the admin dashboard) to start a fresh post.

Here are some suggestions for your first post.

  1. You can find new ideas for what to blog about by reading the Daily Post.
  2. Add PressThis to your browser. It creates a new blog post for you about any interesting  page you read on the web.
  3. Make some changes to this page, and then hit preview on the right. You can alway preview any post or edit you before you share it to the world.