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 ?
Journal Git et Mercurial
5
sept.
2007
# Mercurial...
Posté par Christophe Chailloleau-Leclerc . Évalué à 4.
# Mercurial
Posté par or zax . Évalué à 2.
* 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) . Évalué à 2.
[^] # Re: Mercurial
Posté par abramov_MS . Évalué à 3.
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) . Évalué à 5.
# Darcs
Posté par niol (site web personnel) . Évalué à 3.
(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) . Évalué à 4.
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) . Évalué à 3.
[^] # Re: Darcs
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
# Comparatif des gestionnaires de version
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 3.
# git-svn, git-gui et gitk
Posté par Bonnefille Guilhem (site web personnel) . Évalué à 2.
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 . Évalué à 2.
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.
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)
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 . Évalué à 1.
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) . Évalué à 3.
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 . Évalué à 2.
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) . Évalué à 2.
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 . Évalué à 2.
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.