Quelles sont les forces et faiblesses relatives de Git, Mercurial et Bazaar? [fermé]

Que voient les gens ici comme les forces et les faiblesses relatives de Git, Mercurial et Bazaar?

En considérant chacun d'eux ensemble et par rapport aux systèmes de contrôle de version comme SVN et Perforce, quels problèmes faut-il considérer?

Lors de la planification d'une migration de SVN vers l'un de ces systèmes de contrôle de version distribués, quels facteurs considérez-vous?

Git est très rapide, évolue très bien et est très transparent sur ses concepts. L'inconvénient de ceci est qu'il a une courbe d'apprentissage relativement raide. Un port Win32 est disponible, mais pas tout à fait un citoyen de première classe. Git expose les hachages sous forme de numéros de version aux utilisateurs; cela fournit des garanties (en ce qu'un seul hachage fait toujours référence exactement au même contenu; un attaquant ne peut pas modifier l'historique sans être détecté), mais peut être fastidieux pour l'utilisateur. Git a un concept unique de suivi du contenu des fichiers, même si ce contenu se déplace entre les fichiers, et affiche les fichiers comme des objets de premier niveau, mais ne suit pas les répertoires. Un autre problème avec git est qu'il comporte de nombreuses opérations (telles que rebase) qui facilitent la modification de l'historique (dans un sens - le contenu auquel un hachage fait référence ne changera jamais, mais les références à ce hachage peuvent être perdues); certains puristes (moi y compris) n'aiment pas beaucoup ça.

Bazaar est raisonnablement rapide (très rapide pour les arbres avec un historique peu profond, mais évolue actuellement mal avec la longueur de l'historique), et est facile à apprendre pour ceux qui connaissent les interfaces de ligne de commande des SCM traditionnels (CVS, SVN, etc.). Win32 est considéré comme une cible de premier ordre par son équipe de développement. Il a une architecture enfichable pour différents composants et remplace fréquemment son format de stockage; cela leur permet d'introduire de nouvelles fonctionnalités (comme une meilleure prise en charge de l'intégration avec des systèmes de contrôle de révision basés sur différents concepts) et d'améliorer les performances. L'équipe Bazaar considère le suivi des répertoires et prend en charge le renommage des fonctionnalités de première classe. Bien que des identifiants d'identifiant de révision uniques au monde soient disponibles pour toutes les révisions, les revnos locaux dans l'arborescence (numéros de révision standard, plus proches de ceux utilisés par svn ou d'autres SCM plus conventionnels) sont utilisés à la place des hachages de contenu pour identifier les révisions. Bazaar prend en charge les "caisses légères", dans lesquelles l'historique est conservé sur un serveur distant au lieu d'être copié sur le système local et est automatiquement référencé sur le réseau en cas de besoin; à l'heure actuelle, c'est unique parmi les DSCM.

Les deux ont une certaine forme d'intégration SVN disponible; cependant, bzr-svn est considérablement plus performant que git-svn, en grande partie à cause des révisions de format backend introduites à cette fin. [Mise à jour, à partir de 2014: Le produit commercial tiers SubGit fournit une interface bidirectionnelle entre SVN et Git qui est comparable en fidélité à bzr-svn, et considérablement plus raffinée; Je recommande fortement son utilisation par rapport à git-svn lorsque les contraintes de budget et de licence le permettent].

Je n'ai pas beaucoup utilisé Mercurial, et je ne peux donc pas le commenter en détail - sauf pour noter qu'il, comme Git, a un adressage de hachage de contenu pour les révisions; également comme Git, il ne traite pas les répertoires comme des objets de première classe (et ne peut pas stocker un répertoire vide). Il est cependant plus rapide que tout autre DSCM à l'exception de Git, et a une bien meilleure intégration IDE (en particulier pour Eclipse) que n'importe lequel de ses concurrents. Compte tenu de ses caractéristiques de performance (qui ne sont que légèrement inférieures à celles de Git) et de son support supérieur multiplateforme et IDE, Mercurial peut être attrayant pour les équipes avec un nombre important de membres centrés sur win32 ou liés à l'IDE.

L'une des préoccupations lors de la migration à partir de SVN est que les interfaces graphiques et l'intégration IDE de SVN sont plus matures que celles de n'importe lequel des SCM distribués. De plus, si vous faites actuellement un usage intensif de l'automatisation des scripts de pré-validation avec SVN (c'est-à-dire que les tests unitaires doivent passer avant qu'une validation puisse continuer), vous voudrez probablement utiliser un outil similaire à PQM pour automatiser les demandes de fusion vers vos branches partagées.

SVK est un DSCM qui utilise Subversion comme magasin de sauvegarde, et a une assez bonne intégration avec les outils centrés sur SVN. Cependant, il présente des performances et des caractéristiques d'évolutivité considérablement pires que tout autre DSCM majeur (même Darcs), et doit être évité pour les projets susceptibles de devenir plus importants en termes de longueur d'historique ou de nombre de fichiers.

[À propos de l'auteur: j'utilise Git et Perforce pour le travail, et Bazaar pour mes projets personnels et comme bibliothèque intégrée; d'autres parties de l'organisation de mon employeur utilisent beaucoup Mercurial. Dans une vie antérieure, j'ai construit beaucoup d'automatisation autour de SVN; avant cela, j'ai de l'expérience avec GNU Arch, BitKeeper, CVS et autres. Git était assez rebutant au début - cela ressemblait à GNU Arch dans la mesure où il s'agissait d'un environnement lourd en concept, par opposition à des boîtes à outils conçues pour se conformer au choix de flux de travail de l'utilisateur - mais je suis depuis devenu assez à l'aise avec il].

Steve Streeting du projet Ogre 3D vient de publier (28/09/2009) une entrée de blog sur ce sujet où il fait une comparaison excellente et équilibrée de Git, Mercurial et Bazaar .

En fin de compte, il trouve des forces et des faiblesses avec les trois et aucun gagnant clair. Sur le plan positif, il donne une excellente table pour vous aider à décider avec laquelle aller.

C'est une courte lecture et je le recommande vivement.

Que voient les gens ici comme les forces et les faiblesses relatives de Git, Mercurial et Bazaar?

À mon avis, la force de Git est sa conception sous-jacente propre et son ensemble très riche de fonctionnalités. Il a également, je pense, le meilleur support pour les référentiels multi-branches et la gestion des flux de travail lourds. Il est très rapide et a une petite taille de référentiel.

Il a quelques fonctionnalités qui sont utiles mais qui demandent quelques efforts pour s'y habituer. Ceux-ci incluent un ara intermédiaire visible (index) entre la zone de travail et la base de données du référentiel, ce qui permet une meilleure résolution de fusion dans les cas plus compliqués, le comitting incrémental et le comitting avec un arbre sale; détecter les renommés et les copies en utilisant une heuristique de similitude plutôt que de les suivre en utilisant une sorte d'ID de fichier, qui fonctionne bien et qui permet de blâmer (annoter) qui peut suivre le mouvement du code à travers les fichiers et pas seulement les renommages en gros.

L'un de ses inconvénients est que la prise en charge de MS Windows est à la traîne et n'est pas complète. Un autre inconvénient perçu est qu'il n'est pas aussi bien documenté que Mercurial par exemple, et qu'il est moins convivial que la concurrence, mais cela change.

À mon avis Mercurial force de réside dans ses bonnes performances et sa petite taille de référentiel, dans son bon support MS Windows.

Le principal inconvénient est à mon avis le fait que les branches locales (plusieurs branches dans un seul référentiel) sont toujours des citoyens de seconde classe, et implémentent de manière étrange et compliquée des balises. De plus, la façon dont il traite les renommages de fichiers était sous-optimale (mais cette migration a changé). Mercurial ne prend pas en charge les fusions octopus (avec plus de deux parents).

D'après ce que j'ai entendu et lu principal avantages de Bazaar sont la prise en charge facile du flux de travail centralisé (ce qui est également un inconvénient, avec des concepts centralisés visibles là où il ne devrait pas), le suivi des changements de noms de fichiers et de répertoires.

Son principal inconvénient est la performance et la taille du référentiel pour les grands référentiels avec une longue histoire non linéaire (les performances améliorées au moins pour les référentiels pas trop grands), le fait que le paradigme par défaut est un ranch par référentiel (vous pouvez le configurer pour partager des données, cependant) , et des concepts centralisés (mais cela aussi de ce que j'ai entendu des changements).

Git est écrit en C, en scripts shell et en Perl, et est scriptable; Mercurial est écrit en C (core, pour les performances) et Python, et fournit une API pour les extensions; Bazaar est écrit en Python et fournit une API pour les extensions.

En considérant chacun d'eux ensemble et par rapport aux systèmes de contrôle de version comme SVN et Perforce, quels problèmes faut-il considérer?

Les systèmes de contrôle de version comme Subversion (SVN), Perforce ou ClearCase sont des systèmes de contrôle de version centralisés . Git, Mercurial, Bazaar (ainsi que Darcs, Monotone et BitKeeper) sont des systèmes de contrôle de version distribués . Les systèmes de contrôle de version distribués permettent une gamme beaucoup plus large de flux de travail. Ils permettent d'utiliser "publier quand prêt". Ils ont une meilleure prise en charge pour la création de branches et la fusion, ainsi que pour les flux de travail lourds. Vous n'avez pas besoin de faire confiance aux personnes ayant un accès avec engagement pour pouvoir obtenir des contributions de leur part de manière simple.

Lors de la planification d'une migration de SVN vers l'un de ces systèmes de contrôle de version distribués, quels facteurs considérez-vous?

L'un des facteurs que vous voudrez peut-être prendre en compte est la prise en charge de l'inetracting avec SVN; Git a git-svn, Bazaar a bzr-svn et Mercurial a l'extension hgsubversion.

Clause de non-responsabilité: Je suis un utilisateur Git et un petit contributeur, et je regarde (et je participe à) la liste de diffusion git. Je ne connais Mercurial et Bazaar que par leur documentation, diverses discussions sur IRC et les listes de diffusion, et des articles de blog et des articles comparant divers systèmes de contrôle de version (dont certains sont répertoriés sur la page GitComparison sur Git Wiki).

InfoQ a une belle comparaison .

Mercurial et Bazaar se ressemblent beaucoup en surface. Ils fournissent tous deux un contrôle de version distribué de base, comme dans la validation hors ligne et la fusion de plusieurs branches, sont tous deux écrits en python et sont tous deux plus lents que git. Il existe de nombreuses différences une fois que vous vous êtes plongé dans le code, mais, pour vos tâches quotidiennes de routine, elles sont effectivement les mêmes, bien que Mercurial semble avoir un peu plus d'élan.

Git, eh bien, n'est pas pour les non-initiés. Il est beaucoup plus rapide que Mercurial et Bazaar, et a été écrit pour gérer le noyau Linux. C'est le plus rapide des trois et c'est aussi le plus puissant des trois, de loin. Les outils de manipulation des journaux et des validations de Git sont inégalés. Cependant, c'est aussi le plus compliqué et le plus dangereux à utiliser. Il est très facile de perdre un commit ou de ruiner un référentiel, surtout si vous ne comprenez pas le fonctionnement interne de git.

Jetez un œil à la comparaison faite récemment par les développeurs Python: http://wiki.python.org/moin/DvcsComparison . Ils ont choisi Mercurial pour trois raisons importantes:

Le choix d'utiliser Mercurial a été fait pour trois raisons importantes:

• Selon une petite enquête, les développeurs Python sont plus intéressés par l'utilisation de Mercurial que par Bazaar ou Git.
• Mercurial est écrit en Python, ce qui est conforme à la tendance python-dev à `` manger leur propre dogfood ''.
• Mercurial est nettement plus rapide que bzr (il est plus lent que git, bien que par une différence beaucoup plus petite).
• Mercurial est plus facile à apprendre pour les utilisateurs de SVN que Bazaar.

(à partir de http://www.python.org/dev/peps/pep-0374/ )

Sun a évalué git , Mercurial et Bazaar en tant que candidats pour remplacer le Sun Teamware VCS pour la base de code Solaris. Je l'ai trouvé très intéressant.

Une chose manquante très importante dans le bazar est cp. Vous ne pouvez pas avoir plusieurs fichiers partageant le même historique, comme vous l'avez dans SVN, voir par exemple ici et ici . Si vous ne prévoyez pas d'utiliser cp, bzr est un excellent remplacement (et très facile à utiliser) de svn.

J'utilisais Bazaar pendant un moment, ce que j'aimais beaucoup mais ce n'était que des projets plus petits et même alors c'était assez lent. Si facile à apprendre, mais pas très rapide. C'est cependant très X-Platform.

J'utilise actuellement Git que j'aime beaucoup car la version 1.6 le rend beaucoup plus similaire aux autres VCS en termes de commandes à utiliser.

Je pense que les principales différences dans mon expérience d'utilisation de DVCS sont les suivantes:

1. Git a la communauté la plus dynamique et il est courant de voir des articles sur Git
2. GitHub est vraiment génial. Launchpad.net est ok, mais rien de tel que le plaisir de Github
3. Le nombre d'outils de workflow pour Git a été formidable. Il est intégré partout. Il y en a pour Bzr mais pas autant ni aussi bien entretenus.

En résumé, Bzr était super quand je me faisais les dents sur DVCS mais je suis maintenant très content de Git et Github.

C'est une grande question qui dépend beaucoup du contexte qui vous prendrait beaucoup de temps pour taper dans l'une de ces petites zones de texte. En outre, ces trois éléments semblent sensiblement similaires lorsqu'ils sont utilisés pour les tâches habituelles de la plupart des programmeurs, donc même comprendre les différences nécessite des connaissances assez ésotériques.

Vous obtiendrez probablement de bien meilleures réponses si vous pouvez décomposer votre analyse de ces outils au point où vous avez des questions plus spécifiques.

Bazaar est à mon humble avis plus facile à apprendre que git. Git a un bon support dans github.com.

Je pense que vous devriez essayer d'utiliser les deux et décider ce qui vous convient le mieux.

Que voient les gens ici comme les forces et les faiblesses relatives de Git, Mercurial et Bazaar?

C'est une question très ouverte, à la limite de l'appât à flammes.

Git est le plus rapide, mais les trois sont assez rapides. Bazaar est le plus flexible (il a un support transparent en lecture-écriture pour les référentiels SVN) et se soucie beaucoup de l'expérience utilisateur. Mercurial est quelque part au milieu.

Les trois systèmes ont beaucoup de fanboys. Je suis personnellement un fanboy de Bazaar.

En considérant chacun d'eux ensemble et par rapport aux systèmes de contrôle de version comme SVN et Perforce, quels problèmes faut-il considérer?

Les premiers sont des systèmes distribués. Ces derniers sont des systèmes centralisés. De plus, Perforce est propriétaire alors que tous les autres sont libres comme dans la parole .

Centralisé ou décentralisé est un choix beaucoup plus important que n'importe lequel des systèmes que vous avez mentionnés dans sa catégorie.

Lors de la planification d'une migration de SVN vers l'un de ces systèmes de contrôle de version distribués, quels facteurs considérez-vous?

Tout d'abord, il manque un bon substitut à TortoiseSVN. Bien que Bazaar travaille sur sa propre variante Tortoise , mais ce n'est pas encore là, en septembre 2008.

Ensuite, la formation des personnes clés sur la façon dont l'utilisation d'un système décentralisé va affecter leur travail.

Enfin, l'intégration avec le reste du système, comme les traqueurs de problèmes, le système de construction nocturne, le système de test automatisé, etc.

Votre problème majeur sera qu'il s'agit de SCM distribués et que, en tant que tels, il faudra modifier légèrement l'état d'esprit de l'utilisateur. Une fois que les gens se sont habitués à l'idée, les détails techniques et les modèles d'utilisation se mettront en place, mais ne sous-estimez pas cet obstacle initial, en particulier dans un contexte d'entreprise. Souvenez-vous que tous les problèmes sont des problèmes de personnes.

ddaa.myopenid.com l'a mentionné au passage, mais je pense qu'il vaut la peine de le mentionner à nouveau: Bazaar peut lire et écrire dans des dépôts SVN distants. Cela signifie que vous pouvez utiliser Bazaar localement comme preuve de concept pendant que le reste de l'équipe utilise encore Subversion.

EDIT: Presque tous les outils ont maintenant un moyen d'interagir avec SVN, mais j'ai maintenant une expérience personnelle qui git svnfonctionne extrêmement bien. Je l'utilise depuis des mois, avec un minimum de hoquet.

Il y a une bonne vidéo de Linus Torvalds sur git. Il est le créateur de Git, c'est donc ce qu'il promeut, mais dans la vidéo, il explique ce que sont les SCM distribués et pourquoi ils sont meilleurs que ceux centralisés. Il y a beaucoup de comparaison entre git (mercurial est considéré comme correct) et cvs / svn / perforce. Il y a également des questions du public concernant la migration vers le SCM distribué.

J'ai trouvé ce matériel instructif et je suis vendu à SCM distribué. Mais malgré les efforts de Linus, mon choix est mercuriel. La raison en est bitbucket.org, je l'ai trouvé meilleur (plus généreux) que github.

Je dois dire ici un mot d'avertissement: Linus a un style assez agressif, je pense qu'il veut être drôle mais je n'ai pas ri. En dehors de cela, la vidéo est excellente si vous êtes nouveau dans les SCM distribués et que vous pensez à quitter SVN.

http://www.youtube.com/watch?v=4XpnKHJAok8

Les systèmes de contrôle de version distribués (DVCS) résolvent des problèmes différents de ceux des VCS centralisés. Les comparer, c'est comme comparer des marteaux et des tournevis.

VCS centralisé systèmes sont conçus avec l'intention qu'il y ait une seule vraie source bénie, et donc bonne. Tous les développeurs travaillent (checkout) à partir de cette source, puis ajoutent (valident) leurs modifications, qui deviennent alors également bénies. La seule vraie différence entre CVS, Subversion, ClearCase, Perforce, VisualSourceSafe et tous les autres CVCS réside dans le flux de travail, les performances et l'intégration que chaque produit offre.

Les systèmes VCS distribués sont conçus avec l'intention qu'un référentiel soit aussi bon que n'importe quel autre, et que les fusions d'un référentiel à un autre ne sont qu'une autre forme de communication. Toute valeur sémantique quant au référentiel à faire confiance est imposée de l'extérieur par le processus et non par le logiciel lui-même.

Le vrai choix entre l'utilisation d'un type ou de l'autre est organisationnel - si votre projet ou organisation souhaite un contrôle centralisé, alors un DVCS est un non-starter. Si vos développeurs sont censés travailler dans tout le pays / le monde, sans connexions haut débit sécurisées à un référentiel central, alors DVCS est probablement votre salut. Si vous avez besoin des deux, vous êtes fsck'd.