- Git : C'est le joujou de Linus. très performant sous Linux, mais dès qu'on sort de cet environnement, les performances chutent.
Remplacer "Linux" par "Unix", remplacer "chûtent" par "baissent", et ne pas oublier que Windows ne brille pas de manière générale par les performances brutes de son système de fichiers, et que Cygwin n'arrange rien à l'affaire.
Bref, faut pas croire que Git se traîne en dehors d'Unix, mais il est moins rapide c'est vrai. Il y a eu un gros travail sur les performances sous Cygwin, les principaux problèmes ont été éliminés.
Le renomage de fichiers n'est pas vraiment présent.
Et il n'est pas vraiment nécessaire. C'est CVS qui a obsédé tout le monde avec la gestion du renommage, puisque sous CVS renommer signifie perdre l'historique. Ce problème est énormément minoré quand on gère des changesets. De plus, quand on y regarde de plus près, le renommage de fichiers entiers n'est pas tant fréquent que la copie et le déplacement de portions de code.
Git permet bien sûr de renommer un fichier avec une petite commande toute simple (git-mv). Il n'enregistre pas cette information (l'opération de renommage), mais il permet de détecter automatiquement le renommage et la copie de portions de fichiers, et ça, c'est beaucoup plus intéressant.
Par exemple, entre Git v0.99.1 et v1.0rc4 (purement au hasard), entre autres très nombreuses modifications :
* La moitié de checkout-cache.c s'est retrouvée dans checkout-index.c
* convert-cache.c a été renommé en convert-objects.c
* pull.h a été renommé en fetch.h
* Une bonne partie de ssh-push.c a été copiée dans ssh-upload.c
Ligne de commande :
git-diff-tree -M -C --diff-filter=RC --find-copies-harder v0.99.1 v1.0rc4
Affichage :
(assez moche -- c'est une commande de bas niveau)
C'est sûr que cette fonctionnalité là n'est pas encore très user-friendly, mais elle est là et elle est bien utile.
Ce projet est très en vogue à cause de la notoriété de Linus et de Linux.
S'il maintient sa vogue, c'est aussi par sa qualité, et par effet boule de neige : bon développeurs, bon code et bonne ambiance = encore plus de bons développeurs et de bon code.
C'est un outils concu, développé et utilisé par/pour le noyau linux.
Pas uniquement. Comme le dit Junio Hamano, le mainteneur de Git, Linux n'est "que" le principal client de Git. Linux est important, mais pas au point de compromettre Git.
- Mercurial : Un Git en mieu.
Euh... non. Extrêmement similaire (à égalité technique avec Git pour OpenSolaris qui vient de les évaluer, et pourtant Git c'est GNU/Linux, et les développeurs d'OpenSolaris ne sont pas super fans des outils GNU et de Linux) (OpenSolaris a préféré Mercurial pour des raisons de poil brillant et d'un support promis par un développeur-clé de Mercurial).
moins bidouille
Ah non. La plupart de Git est bien écrit et bien conçu, tout comme la plupart de Mercurial. Dans les deux, il y a des recoins un peu bidouillés qui peuvent bénéficier d'un petit coup de balai.
- darcs : semble avoir lancé des idées interessantes et boulversé les mentalités.
Des idées intéressantes, tout à fait, bouleversé les mentalités, faut pas exagérer quand même. Il a par contre été le premier à ma connaissance à montrer à quel point on pouvait faire une interface claire et facile à apprendre (une leçon que Mercurial a bien compris) et à mettre ses données dans un sous-répertoire local (plutôt que dans une arborescence à part centralisée pour tous les projets hébergés sur la machine, genre cvsroot etc.). Git et Mercurial ont repris cette excellente idée.
Il semble avoir des problèmes de performances assez importantes
Ah oui.
il n'y a pas de (grosse) communauté autour à cause de son language de programmation, Haksel.
Ben en fait il a toute la communauté Haskell, donc ça fait pas mal de gars très intelligents. Mais j'ai pas suivi ces derniers mois.
[^] # Re: Les RVS décentralisés
Posté par Boa Treize (site web personnel) . En réponse à la dépêche Sortie de Git 1.3.0. Évalué à 3.
Remplacer "Linux" par "Unix", remplacer "chûtent" par "baissent", et ne pas oublier que Windows ne brille pas de manière générale par les performances brutes de son système de fichiers, et que Cygwin n'arrange rien à l'affaire.
Bref, faut pas croire que Git se traîne en dehors d'Unix, mais il est moins rapide c'est vrai. Il y a eu un gros travail sur les performances sous Cygwin, les principaux problèmes ont été éliminés.
Et il n'est pas vraiment nécessaire. C'est CVS qui a obsédé tout le monde avec la gestion du renommage, puisque sous CVS renommer signifie perdre l'historique. Ce problème est énormément minoré quand on gère des changesets. De plus, quand on y regarde de plus près, le renommage de fichiers entiers n'est pas tant fréquent que la copie et le déplacement de portions de code.
Git permet bien sûr de renommer un fichier avec une petite commande toute simple (git-mv). Il n'enregistre pas cette information (l'opération de renommage), mais il permet de détecter automatiquement le renommage et la copie de portions de fichiers, et ça, c'est beaucoup plus intéressant.
Par exemple, entre Git v0.99.1 et v1.0rc4 (purement au hasard), entre autres très nombreuses modifications :
* La moitié de checkout-cache.c s'est retrouvée dans checkout-index.c
* convert-cache.c a été renommé en convert-objects.c
* pull.h a été renommé en fetch.h
* Une bonne partie de ssh-push.c a été copiée dans ssh-upload.c
Ligne de commande :
git-diff-tree -M -C --diff-filter=RC --find-copies-harder v0.99.1 v1.0rc4
Affichage :
(assez moche -- c'est une commande de bas niveau)
C'est sûr que cette fonctionnalité là n'est pas encore très user-friendly, mais elle est là et elle est bien utile.
S'il maintient sa vogue, c'est aussi par sa qualité, et par effet boule de neige : bon développeurs, bon code et bonne ambiance = encore plus de bons développeurs et de bon code.
Pas uniquement. Comme le dit Junio Hamano, le mainteneur de Git, Linux n'est "que" le principal client de Git. Linux est important, mais pas au point de compromettre Git.
Euh... non. Extrêmement similaire (à égalité technique avec Git pour OpenSolaris qui vient de les évaluer, et pourtant Git c'est GNU/Linux, et les développeurs d'OpenSolaris ne sont pas super fans des outils GNU et de Linux) (OpenSolaris a préféré Mercurial pour des raisons de poil brillant et d'un support promis par un développeur-clé de Mercurial).
Ah non. La plupart de Git est bien écrit et bien conçu, tout comme la plupart de Mercurial. Dans les deux, il y a des recoins un peu bidouillés qui peuvent bénéficier d'un petit coup de balai.
Des idées intéressantes, tout à fait, bouleversé les mentalités, faut pas exagérer quand même. Il a par contre été le premier à ma connaissance à montrer à quel point on pouvait faire une interface claire et facile à apprendre (une leçon que Mercurial a bien compris) et à mettre ses données dans un sous-répertoire local (plutôt que dans une arborescence à part centralisée pour tous les projets hébergés sur la machine, genre cvsroot etc.). Git et Mercurial ont repris cette excellente idée.
Ah oui.
Ben en fait il a toute la communauté Haskell, donc ça fait pas mal de gars très intelligents. Mais j'ai pas suivi ces derniers mois.