Journal Git et Mercurial

Posté par Fabien Penso (site web personnel, Mastodon) le 05 septembre 2007 à 16:59.

Étiquettes : aucune

sept.

2007

Cher journal,

Suite à un billet sur Git et Mercurial sur mon blog : http://blog.penso.info/2007/09/04/conference-de-linus-torval(...) je me demandais lequel vous utilisiez et pour quelle raison. Les deux ont des avantages et des inconvénients. Git semble plus rapide mais plus obscure, Mercurial plus propre et avec moins de commandes.

Lequel utilisez-vous et pour quelle raison ? Quel retour d'experience avez-vous ?

# Mercurial...

Posté par Christophe Chailloleau-Leclerc le 05 septembre 2007 à 17:19. Évalué à 4.

... pour sa portabilité
# Mercurial

Posté par or zax le 05 septembre 2007 à 17:20. Évalué à 2.

* Pour le côté multiplateforme qui rend plus aisé l'utilisation en entreprise lorsque l'on a pas la main sur le choix de L'OS du poste de travail.

* Quand j'avais regardé GIT, je n'ai rien compris à la doc, à l'époque, on parlait d'utiliser cogito pour le rendre ergonomiquement 'human being friendly', à l'heure actuelle je suppose que cet aspect n'est plus un problème.
- [^] # Re: Mercurial
  
  Posté par Fabien Penso (site web personnel, Mastodon) le 05 septembre 2007 à 17:27. Évalué à 2.
  
  Oui c'est effectivement ce qui ressort de GIT encore actuellement (même si ça s'est amélioré)
- [^] # Re: Mercurial
  
  Posté par abramov_MS le 05 septembre 2007 à 20:47. Évalué à 3.
  
  GIT avec la version 1.5.2 au moins (celle que j'ai) c'est super super simple a utiliser. C'est exactement ce que je cherchais comme logiciel. Il est simple, puissant et fonctionne sans installation de serveur a la cvs. Franchement j'adore.
  
  je connais pas les autres je dois avouer mais git je n'ai rien a lui reprocher du tout.
# journal comparatif

Posté par BAud (site web personnel) le 05 septembre 2007 à 17:59. Évalué à 5.

cet été, il y a eu ce journal sur git https://linuxfr.org/~moy/25128.html où quelques comparaisons à mercurial et bazaar ont été faites (plus techniques qu'orientées ergonomie).
# Darcs

Posté par niol (site web personnel) le 05 septembre 2007 à 18:17. Évalué à 3.

J'utilise darcs car lorsque la question s'est posée, c'était le seul qui permettait d'enregistrer seulement un changement dans un fichier et pas forcément tous les changements d'un fichier.
(c'est maintenant apparemment possible avec mercurial au moins grâce à http://www.selenic.com/mercurial/wiki/index.cgi/RecordExtens(...) )

mercurial était trop jeune et git trop compliqué en apparence. J'aime la simplicité "un dépot, une seule branche". Darcs s'apprend en quelques minutes. Ca c'est vraiment bien.

De plus, je ne me suis pas encore heurté de manière bloquante aux problèmes connus de darcs (voir http://wiki.darcs.net/DarcsWiki/FrequentlyAskedQuestions#hea(...) )
- [^] # Re: Darcs
  
  Posté par Matthieu Moy (site web personnel) le 05 septembre 2007 à 19:03. Évalué à 4.
  
  > enregistrer seulement un changement dans un fichier et pas forcément tous les changements d'un fichier.
  
  git permet aussi de commiter des "patch hunks" individuellement.
  
  Dans "git gui", tu as les changements prêts à être commités à gauche, en vert, et les changement non sélectionnés pour le commit, à droite, en rouge. Dans le diff, en bas de la fenêtre, tu peux faire clic-droit -> stage hunk for commit / unstage hunk from commit.
  
  En ligne de commande, tu as "git add -i" qui fait ça, et permet même de couper un "patch hunk" en morceaux. (attention, git add ne fait pas ce que la plupart des autres XXX add font : il ajoute un changement - par défaut, un fichier - au commit qui se prépare).
  
  Mais attention, il faut se méfier des commits selectifs. Quand on fait ce genre de trucs, on commite quelque chose qui n'a probablement jamais existé sur le disque, et donc, qui n'a jamais été testé.
  
  > J'aime la simplicité "un dépot, une seule branche".
  
  Rien ne t'empêche d'utiliser git et mercurial de cette façon. Tu n'as pas besoin de savoir qu'il y a la possibilité d'avoir plusieurs branches dans le même repository pour les utiliser.
  
  > De plus, je ne me suis pas encore heurté de manière bloquante aux problèmes connus de darcs
  
  J'ai utilisé un peu Darcs, j'ai trouvé l'interface utilisateur bien foutue, claire.
  
  Par contre, je ne l'ai pas choisi pour plusieurs raisons :
  
  * Les performances. Pour les projets que je gère, c'est pas un vrai problème, ils sont suffisament petits, mais je veux que le gestionnaire de version que j'utilise puisse passer à l'échelle, pouvoir utiliser la même chose pour moi que les gros projets. C'est une garantie que mes connaissances pourront être réutilisées, et une garantie de pérénité pour le projet (peu de risque que git ou Mercurial soient abandonnés du jour au lendemain vu les enjeux, alors que dieu seul sait ce qu'il se passerait si l'auteur de Darcs décidait d'arrêter de le maintenir).
  
  * L'approche orientée patch. L'historique est une succession de patchs qui ont potentiellement été réordonnés, donc, la série de patchs ne corresponds pas forcément à une série d'états qui ont vraiment existé dans l'histoire.Résultat, tu ne peux pas revenir à un état passé de ton arbre de travail. Tu ne peux pas non plus dire « j'ai un problème avec la version XYZ, est-ce que vous l'avez aussi ». Avec git ou Mercurial, si je te dis que j'ai un problème avec la révision 2f82f760e1b263, c'est non ambigu, tous les développeurs savent de quoi je parlent (même arbre de travail, même historique).
  - [^] # Re: Darcs
    
    Posté par MrLapinot (site web personnel) le 05 septembre 2007 à 20:07. Évalué à 3.
    
    Globalement d'accord, sauf pour ton dernier point. darcs tag est ton ami.
    - [^] # Re: Darcs
      
      Posté par Matthieu Moy (site web personnel) le 06 septembre 2007 à 08:49. Évalué à 2.
      
      Oui, mais pour moi, le fait de pouvoir être sûr de revenir exactement dans le même état plus tard, et de pouvoir parler de cet état avec d'autres gens, ça devrait être la norme, pas l'exception.
# Comparatif des gestionnaires de version

Posté par Thierry Thomas (site web personnel, Mastodon) le 05 septembre 2007 à 22:26. Évalué à 3.

Il y a une étude intéressante sur le wiki de FreeBSD, avec un tableau comparatif des systèmes envisagés : Cf. [http://wiki.freebsd.org/VersionControl].
# git-svn, git-gui et gitk

Posté par Bonnefille Guilhem (site web personnel) le 06 septembre 2007 à 10:39. Évalué à 2.

Moi, j'utilise Git. La raison initiale est que c'est le premier que j'ai découvert quand je suis rentré dans le monde de la gestion de version décentralisée.

Maintenant, je me sers exclusivement de Git comme "frontend" à mes dépots SVN. Du coup, au jour le jour je me sers de :
- git-svn pour synchroniser mes dépots Git et mes dépots SVN
- git-gui pour fabriquer les commit
- gitk pour me ballader dans l'historique

Grâce à git-gui et gitk je ne tape JAMAIS de commande Git. Alors le fait que Git propose plus de 150 commandes... ça ne me gène pas outre mesure au jour le jour.

Sinon, j'essaye de bosser sur giggle, une interface graphique à Git en Gtk+ : http://developer.imendio.com/projects/giggle
# Ton blog

Posté par Bozo_le_clown le 06 septembre 2007 à 11:04. Évalué à 2.

Puisque tu nous invites gentillement à lire ton billet, j'aurais quelques remarques à faire dessus

les auteurs de BitKeeper et Linus ont convenu qu’il fallait mieux que Linus se mette à utiliser autre chose.

J'avais plutot l'impression que c'etait le changement de cap de BitMover qui interdisait d'utiliser Bitkeeper à tout developpeur de projet libre qui travaillerait sur un projet de VCS concurrent, et qui a ensuite décidé de faire payer l'tuilsatuion de Bitkeeepr y compris pour les projets libres mais je peux me tromper.

On travaille sur une nouvelle fonctionnalité. On pense qu’elle nous prendra 6H, mais en vérité on ne le sait pas vraiment. À la fin de la journée la fonctionnalité n’est pas terminée, et au final on aura mis 3 jours. Entre temps on n’a fait aucun commit pour ne pas casser le repository central ou avoir une instabilité du repository qui fera gueuler tous les autres développeurs. Avec un DSCM on peut commiter tranquillement dans sa version locale, pour envoyer les modifications une fois tout le code testé et terminé. On peut même envisager de développer cette fonctionnalité dans une branche locale invisible aux autres développeurs, et continuer de développer la branche principale indépendemment si besoin est.

Ah c'est vrai que la notion de branche n'existe pas avec les VCS centralisés. Comme si se créer un dépot n'était pas equivalent à une bonne pratique qui consiste à créer une branche par developpeur sytématiquement.
Par ailleurs c'est vrai qu'on ne peut pas attendre 3 jours de plus pour commiter.
Le vrai avantage est de pouvoir commiter plusieurs fois en étant déconnecté du serveur et de pouvoir contribuer à un projet sans obtenir de privilèges sur le dépôt et sans sortir du contrôle du VCS (diff/patch)

Git et Mercurial peuvent être utilisés de multiples manières, à la CVS avec un serveur central sur lequel toutes les modifications sont envoyées, ou sans serveur central.

La différence entre un DVCS et un VCS centralisé n'est pas le fait d'utiliser un serveur central pour envoyer ses modification(il faut bien un dépôt central pour diffuser un logiciel de toute façon) mais le fait que plusieurs utilisateurs peuvent travailler en concurrence d'accès sur une même branche. Le modèle de base du DVCS isole chaque utilisateur dans sa branche et chaque utilisateur récupère les modifs des autres dans sa branche par merge après les avoir récupére dans son dépôt. Il est seul maître de sa branche (user centric).
Cette confusion provient surtout des DVCS qui ne différencient pas la notion de branche et de dépôt.
Comme le faisait judicieusement remarquer Mathieu Moy dans un autre journal, seul bzr supporte complètement les 2 approches
https://linuxfr.org/comments/860025.html#860025.
- [^] # Re: Ton blog
  
  Posté par or zax le 06 septembre 2007 à 17:02. Évalué à 1.
  
  Bzr n'est pas le seul à gérer les deux approches, GNU Arch gère les deux cas depuis le début.
  
  De plus il est pas évident de comparer la notion de branches entre un système centralisé ou non, chacun utilisant ce terme pour désigner des choses différentes, je pense surtout à la notion de branche de SVN notamment.
  - [^] # Re: Ton blog
    
    Posté par Matthieu Moy (site web personnel) le 06 septembre 2007 à 19:30. Évalué à 3.
    
    On pourrait disserter des heures là dessus, mais GNU Arch n'est pas « décentralisé » dans le même sens que les autres (git/bzr/hg/mtn/...) : Avec par exemple git, quand je fais "git clone git://kernel.org/l/archive/de/linus/", je me retrouve avec quelque chose qui est techniquement équivalent à la branche de Linus, mais sur mon ordinateur. Ce n'est pas « une branche de ... », c'est vraiment le même. D'ailleurs, si je suis hyper intelligent, si ça se trouve, un jour, les gens trouveront que c'est ma branche qui doit être la référence, et celle de Linus qui est un clone de la mienne.
    
    Avec GNU Arch, on distingue deux choses :
    
    * La notion de mirroir. Oui, je peux faire un mirroir d'une archive, mais ce n'est pas quelque chose d'équivalent : le mirroir est read-only, je ne peux pas commiter dessus.
    
    * La notion de "tag" (ou branche, en fait). Je peux dire "ma branche est le successeur de la branche officielle", et là, je peux commiter. Mais c'est ma branche. Elle a une identité différente, ...
    
    Avec les autres systèmes, les deux notions sont confondues. Ça a l'air subtil, mais c'est une différence pas négligeable. Par exemple, avec git, si je parle de la revision 2ab504fe, je peux avoir cette révision, peut-être que quelqu'un d'autre l'aura aussi dans son archive, ... Avec GNU Arch, si je parle de la revision Matthieu.Moy@imag.fr--arch/xxx--yyy--zzz--patch-42, c'est une révision qui est dans mon archive et dans celle de personne d'autre.
    - [^] # Re: Ton blog
      
      Posté par Bozo_le_clown le 07 septembre 2007 à 20:55. Évalué à 2.
      
      Je crois qu'en dehors de bzr, svk supporte aussi les 2 modèles étant donné qu'iil s'agit d'une variante de Subversion distribuée. Tu dois pouvoir accéder de façon concurrent sur la même.
      
      Monotone a une approche originale. A la différence de la plupart des outils qui considère les branches comme une séquence de versions ou de patchs, dans une branche monotone une version peut avoir plusieurs filles. Une branche est un DAG au lieu d'être une ligne. Lorsqu' une branche a plusieurs feuilles après avoir récupéré des mises à jour d'autres archives tu dois les réconcilier. Je trouve cette approche vraiment élégante.
      
      A la différence d'une approche centralisée tu peux committer tes versions intermédiaires sans te soucier de réconcilier avec les version concurrentes avant le commit. Avec un outil centralisé tu dois merger au préalable.
      
      A la différence des autres DVCS, tout le monde travaille sur la même branche sans penser à quelle branche parente on doit se raccrocher. Tu n'est pas obligé de te créer une branche dédiée pour corriger une version.
      - [^] # Re: Ton blog
        
        Posté par Matthieu Moy (site web personnel) le 08 septembre 2007 à 17:45. Évalué à 2.
        
        > Monotone a une approche originale. [...] une version peut avoir plusieurs filles.
        
        Oui, mais c'est ce que font la plupart des gestionnaires de versions actuels (enfin, sauf si on considère Subversion comme un gestionnaire de versions :-P ). bzr, hg, git au moins sont basés sur le même principe.
  - [^] # Re: Ton blog
    
    Posté par Bozo_le_clown le 07 septembre 2007 à 22:07. Évalué à 2.
    
    Une branche est une branche. Avec SVN un "svn cp" te crées une branche comme une autre. La seule différence est qu'elle est présentée dans ton arborescence. Dès que tu modifies un fichier dans le sous-répertoire tu fais évoluer ce fichier en parallèle et si tu l'édites plusieurs fois tu as plusieurs versions du même fichier qui se succèdent i.e. ...une branche.
    
    L'avantage du "svn cp" est surtout pour marquer une baseline . En O(1), tu peux tagger une arborescence entière alors que d'autres outils obtiennent le même résultat en O(n) (n étant le nombre de fichiers de ton arbo).
    L'autre avantage c'est que c'est assez naturel. Sans VCS tu ferais une copie de ton arbo dans un autre répertoire pour la forker et la modifier ou pour la tagger.
    Là tu fais la même chose mais tu bénéficies de tous les avantages du VCS pour les merge ... et surtout c'est instantané.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.