* mercurial: plus facile d'accès, moins intimidant, on peut tout de suite commencer. On sent vraiment le côté user-friendly voulu par les auteurs. De la très bonne documentation, entre le wiki, le hgbook [http://hgbook.red-bean.com], et des tutoriels du type [http://hginit.com]
* git: souvent présenté de façon plus technique, plus touffue. Beaucoup de commandes, les man pages peuvent sembler un peu plus repoussantes vu le nombre de switches. Il faut apprendre à faire le tri et se concentrer sur l'essentiel. On peut avoir sans entrer dans les détails une bonne vue d'ensemble via [http://progit.org/book]
C'est peut être subjectif, mais en tout cas j'ai trouvé que pour pouvoir se servir de git, il est rapidement très utile de se donner la peine de comprendre le data-model sous-jacent (commit, tree, blobs etc...). Pour les fonctionalités relatives à la manipulation de l'historique ou aux merges avancés, c'est carrément indispensable. Franchement, le data-model semble particulièrement élégant/séduisant, et paradoxalement assez simple.
Une fois qu'on a dépassé l'étape de la découverte, on se rend vite compte que les deux scms répondront assez facilement à la plupart des besoins.
Ensuite, d'un point de vue pragmatique, l'énorme avantage de hg est que vues ses dépendances (python + je crois un peu de C), il est utilisable sur tous les os, il peut être facilement intégré dans des IDEs. On peut trouver des GUIs pratiques etc...
C'est exactement là ou git pêche un peu: par exemple, même si des efforts ont été faits ou sont en cours pour rapatrier certaines fonctionalités dans des libs, on a droit à du perl, du shell script etc... De plus, git a été développé pour linux, msysgit (le portage officiel sous windows) n'est pas aussi performant mais reste utilisable.. Les GUIs sont plus rares et semblent moins abouties.
Bref, git semble plus puissant que hg pour les fonctionnalités avancées (grâce à son data model sous-jacent avec plus de potentiel) mais il est d'un abord pas facile (doc, déploiement sur des os différents etc..). Au contraire, hg semble avoir moins de potentiel d'un point de vue purement technique, par contre l'utilisateur est choyé (déploiement aisé, doc, outils etc...)
[^] # Re: Git et Mercurial
Posté par ggins . En réponse au sondage Mon logiciel de Logiciel de gestion de versions favori est :. Évalué à 0.
* git: souvent présenté de façon plus technique, plus touffue. Beaucoup de commandes, les man pages peuvent sembler un peu plus repoussantes vu le nombre de switches. Il faut apprendre à faire le tri et se concentrer sur l'essentiel. On peut avoir sans entrer dans les détails une bonne vue d'ensemble via [http://progit.org/book]
C'est peut être subjectif, mais en tout cas j'ai trouvé que pour pouvoir se servir de git, il est rapidement très utile de se donner la peine de comprendre le data-model sous-jacent (commit, tree, blobs etc...). Pour les fonctionalités relatives à la manipulation de l'historique ou aux merges avancés, c'est carrément indispensable. Franchement, le data-model semble particulièrement élégant/séduisant, et paradoxalement assez simple.
Une fois qu'on a dépassé l'étape de la découverte, on se rend vite compte que les deux scms répondront assez facilement à la plupart des besoins.
Ensuite, d'un point de vue pragmatique, l'énorme avantage de hg est que vues ses dépendances (python + je crois un peu de C), il est utilisable sur tous les os, il peut être facilement intégré dans des IDEs. On peut trouver des GUIs pratiques etc...
C'est exactement là ou git pêche un peu: par exemple, même si des efforts ont été faits ou sont en cours pour rapatrier certaines fonctionalités dans des libs, on a droit à du perl, du shell script etc... De plus, git a été développé pour linux, msysgit (le portage officiel sous windows) n'est pas aussi performant mais reste utilisable.. Les GUIs sont plus rares et semblent moins abouties.
Bref, git semble plus puissant que hg pour les fonctionnalités avancées (grâce à son data model sous-jacent avec plus de potentiel) mais il est d'un abord pas facile (doc, déploiement sur des os différents etc..). Au contraire, hg semble avoir moins de potentiel d'un point de vue purement technique, par contre l'utilisateur est choyé (déploiement aisé, doc, outils etc...)