Quelles sont les forces et faiblesses relatives de Git, Mercurial et Bazaar? [fermé]
https://stackoverflow.com/questions/77485
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
Que voient ici les forces et les faiblesses relatives de Git, Mercurial et Bazaar?
Quels sont les problèmes à prendre en compte lorsqu’on examine chacun d’entre eux et par rapport aux systèmes de contrôle de version comme SVN et Perforce?
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 prendriez-vous en compte?
La solution
Git est très rapide, évolue très bien et est très transparent quant à ses concepts. L'inconvénient est qu'il a une courbe d'apprentissage relativement abrupte. 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; ceci fournit des garanties (en ce sens qu'un simple hachage fait toujours référence au même contenu; un attaquant ne peut pas modifier l'historique sans être détecté), mais peut être encombrant pour l'utilisateur. Git a un concept unique de suivi du contenu des fichiers, même lorsque ce contenu est déplacé entre les fichiers, et considère 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 (en un sens, le contenu référencé par un hachage ne changera jamais, mais les références à ce hachage peut être perdu); certains puristes (dont moi-même) n'aiment pas beaucoup cela.
Bazaar est relativement rapide (très rapide pour les arbres dont l'historique est peu profond, mais s'adapte mal à la longueur de l'historique), et est facile à apprendre pour ceux qui connaissent bien 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 possède une architecture enfichable pour différents composants et remplace fréquemment son format de stockage. Cela leur permet d'introduire de nouvelles fonctionnalités (telles qu'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 de Bazaar considère que le suivi des annuaires et le changement de nom prennent en charge des fonctionnalités de premier ordre. Bien que des identifiants de révision d'identification globaux uniques soient disponibles pour toutes les révisions, les revnos arborescentes (numéros de révision standard, plus proches de ceux utilisés par svn ou d'autres MSC plus conventionnels) sont utilisés à la place des hachages de contenu pour identifier les révisions. Bazaar prend en charge les "extractions légères", dans lesquelles l'historique est conservé sur un serveur distant au lieu d'être copié sur le système local et automatiquement référencé sur le réseau lorsque cela est nécessaire; à l’heure actuelle, c’est unique parmi les DSCM.
Tous les deux ont une forme d'intégration SVN disponible; Cependant, bzr-svn est considérablement plus performant que git-svn, en grande partie grâce aux révisions de format de back-end introduites à cette fin. [Mise à jour, à partir de 2014: le produit commercial tiers SubGit fournit une interface bidirectionnelle entre SVN et Git comparable en fidélité à bzr-svn et considérablement améliorée. Je recommande vivement de l’utiliser plutôt que de 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 en parler en détail - sauf pour noter qu'il, comme Git, dispose d'un adressage de hachage de contenu pour les révisions; tout 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). Cependant, il est plus rapide que tout autre DSCM, à l'exception de Git, et offre une intégration IDE nettement supérieure (en particulier pour Eclipse) à celle de ses concurrents. Compte tenu de ses caractéristiques de performances (qui ne sont que légèrement inférieures à celles de Git) et de son support multiplateforme et IDE supérieur, Mercurial pourrait être attrayant pour les équipes comptant un nombre important de membres liés à win32 ou à l'IDE.
Un problème lié à la migration à partir de SVN réside dans le fait que les interfaces d’interface graphique et l’intégration IDE de SVN sont plus matures que celles de tous les GDS distribués. De plus, si vous utilisez actuellement beaucoup l'automatisation des scripts précommit avec SVN (c.-à-d. Si vous souhaitez que les tests unitaires soient réussis avant qu'une validation puisse être exécutée), vous souhaiterez probablement utiliser un outil similaire à PQM pour l’automatisation des demandes de fusion vers vos branches partagées.
SVK est un DSCM qui utilise Subversion comme support de stockage et présente une très bonne intégration avec les outils centrés sur SVN. Cependant, ses caractéristiques de performance et d’évolutivité sont bien pires que celles de tout autre DSCM majeur (même Darcs), et il convient de l’éviter pour les projets susceptibles de devenir volumineux en termes de longueur de l’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; Les autres secteurs de l’organisation de mon employeur utilisent beaucoup Mercurial. Dans une vie antérieure, j'ai construit beaucoup d'automatisation autour de SVN; auparavant, j'ai de l'expérience avec GNU Arch, BitKeeper, CVS et d'autres. Git était plutôt rebutant au début - il me semblait que GNU Arch était un environnement lourd en termes de concept, par opposition aux kits d'outils conçus pour se conformer au choix des utilisateurs en matière de flux de travail - mais je suis depuis devenu assez à l'aise avec il].
Autres conseils
Steve Streeting du projet Ogre 3D (28/09/2009) vient de publier une entrée de blog sur ce sujet dans laquelle il fait un excellent travail comparaison entre Git, Mercurial et Bazaar .
À la fin, il trouve des forces et des faiblesses avec les trois et aucun gagnant clair. Pour ce qui est des points positifs, il propose une excellente table pour vous aider à choisir celle qui vous convient.
C'est une courte lecture et je le recommande vivement.
Que voient ici les forces et les faiblesses relatives de Git, Mercurial et Bazaar?
À mon avis, la force de Git réside dans son design sous-jacent épuré et son ensemble très riche en fonctionnalités. Je pense également qu'il constitue le meilleur support pour les référentiels multi-branches et la gestion de workflows chargés en branches. Il est très rapide et possède un dépôt de petite taille.
Certaines fonctionnalités sont utiles, mais il faut s’efforcer de s’y habituer. Ceux-ci incluent visible un espace intermédiaire intermédiaire (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 les plus compliqués, la validation incrémentielle et la validation avec un arbre modifié; détectant renomme et copie à l'aide d'une méthode heuristique de similarité plutôt que de les suivre à l'aide d'une sorte d'identificateur de fichier, qui fonctionne bien et permet de blâmer (annoter) ce qui peut suivre le mouvement du code entre les fichiers et pas seulement les renommés en gros.
Un de ses inconvénients est que le support de MS Windows est à la traîne et qu’il n’est pas complet. Un autre inconvénient perçu est qu’il n’est pas aussi bien documenté que Mercurial, par exemple, et moins convivial que la concurrence, mais cela change.
À mon avis, la force de Mercurial réside dans ses bonnes performances et la petite taille de son référentiel, ainsi que dans son bon support MS Windows.
Le principal inconvénient est, à mon avis, le fait que les branches locales (plusieurs branches dans un même référentiel) sont toujours des citoyens de seconde classe et qu’elles implémentent des balises de manière étrange et compliquée. De plus, la façon dont il traite les renommage de fichiers était sous-optimale (mais cette tendance a changé). Mercurial ne prend pas en charge la fusion de pieuvres (avec plus de deux parents).
D'après ce que j'ai entendu et lu, les principaux avantages de Bazaar sont la prise en charge simplifiée du flux de travail centralisé (ce qui est également un inconvénient, avec des concepts centralisés visibles là où il ne devrait pas l'être), le suivi des renommements des deux répertoires.
Son principal inconvénient est la performance et la taille du référentiel pour les référentiels volumineux avec un long historique non linéaire (performances améliorées au moins pour les référentiels peu volumineux), le fait que le paradigme par défaut est un ranch par référentiel (vous pouvez le configurer pour partager des données). , bien que), et les 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 (noyau, pour la performance) et en Python, et fournit une API pour les extensions; Bazaar est écrit en Python et fournit une API pour les extensions.
Quels sont les problèmes à prendre en compte?Si vous examinez chacun d'eux l'un avec l'autre et par rapport à des systèmes de contrôle de versions comme SVN et Perforce, Les systèmes de contrôle de version tels que 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 de flux de travail beaucoup plus large. Ils permettent d’utiliser "Publier dès qu’il est prêt". Ils prennent mieux en charge les branches et les fusions, ainsi que les flux de travail chargés en branches. Vous n'avez pas besoin de faire confiance aux personnes disposant d'un accès aux droits pour pouvoir obtenir facilement des contributions de leur part.
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 prendriez-vous en compte?
L’un des facteurs à prendre en compte est l’aide à la pénétration avec SVN; Git a git-svn, Bazaar a bzr-svn et Mercurial a l'extension hgsubversion.
Clause de non-responsabilité: , utilisateur de Git, contributeur ponctuel, et visionnant la liste de diffusion git (et y participant). Je ne connais Mercurial et Bazaar que par leur documentation, diverses discussions sur les listes de diffusion et IRC, ainsi que sur des articles de blogues et des articles comparant divers systèmes de contrôle de version (dont certains sont répertoriés sur page GitComparison sur le wiki de Git).
InfoQ a une belle comparaison .
Mercurial et Bazaar se ressemblent beaucoup à la surface. Ils fournissent tous deux un contrôle de version distribuée de base, comme dans la validation hors ligne et la fusion de plusieurs branches, ils sont tous deux écrits en python et sont plus lents que git. Il existe de nombreuses différences une fois que vous explorez le code, mais, pour vos tâches quotidiennes routinières, elles sont en réalité les mêmes, bien que Mercurial semble avoir un peu plus de dynamisme.
Git, eh bien, ce 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 de journal et de validation de Git sont incomparables 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 dépôt, surtout si vous ne comprenez pas le fonctionnement interne de git.
Jetez un coup d’œ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 un petit sondage, les développeurs Python seraient plus intéressés par l'utilisation de Mercurial que dans Bazar ou Git.
- Mercurial est écrit en Python, ce qui est conforme à la tendance des pythons-dev à "manger leur propre nourriture pour chiens".
- Mercurial est nettement plus rapide que bzr (plus lent que git, bien que la différence soit beaucoup moins grande).
- Mercurial est plus facile à apprendre pour les utilisateurs de SVN que Bazaar.
J'utilisais Bazaar pendant un moment qui me plaisait beaucoup, mais il ne s'agissait que de projets plus petits et même alors, c'était plutôt lent. Tellement facile à apprendre, mais pas très rapide. C'est très x-plate cependant.
J'utilise actuellement Git, qui me plaît beaucoup depuis la version 1.6, qui le rend beaucoup plus similaire aux autres VCS en termes de commandes à utiliser.
Je pense que les principales différences de mon expérience d'utilisation du DVCS sont les suivantes:
- Git a la communauté la plus vibrante et il est courant de voir des articles sur Git
- GitHub est vraiment génial. Launchpad.net est ok, mais rien de tel que le plaisir de Github
- Le nombre d'outils de workflow pour Git a été formidable. C'est intégré partout. Il y en a pour le BZR mais pas aussi nombreux ni aussi bien entretenus.
En résumé, Bzr était génial quand je me coupe les dents sur DVCS mais je suis maintenant très heureux avec Git et Github.
C’est une grande question qui dépend beaucoup du contexte et 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. Même pour comprendre les différences, cela nécessite des connaissances assez ésotériques.
Vous obtiendrez probablement de bien meilleures réponses si vous pouviez décomposer votre analyse de ces outils au point de poser des questions plus spécifiques.
Bazaar est à mon humble avis plus facile à apprendre que git. Git a un support intéressant sur github.com.
Je pense que vous devriez essayer d'utiliser les deux et décider lequel vous convient le mieux.
Que voient ici les forces et les faiblesses relatives de Git, Mercurial et Bazaar?
C’est une question très ouverte, qui touche à la flamme vive.
Git est le plus rapide, mais les trois sont assez rapides. Bazaar est le plus flexible (il prend en charge en lecture-écriture les référentiels SVN) et se soucie beaucoup de l'expérience utilisateur. Mercurial se situe quelque part au milieu.
Les trois systèmes ont beaucoup de fanboys. Je suis personnellement un fan de bazar.
Quels sont les problèmes à prendre en compte lorsqu’on examine chacun d’entre eux et par rapport aux systèmes de contrôle de version comme SVN et Perforce?
Les premiers sont des systèmes distribués. Ces derniers sont des systèmes centralisés. De plus, Perforce est une propriété tandis que tous les autres sont gratuits comme dans le discours .
Centré ou décentralisé est un choix beaucoup plus important que n’importe lequel des systèmes 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 prendriez-vous en compte?
Tout d’abord, l’absence d’un bon substitut à TortoiseSVN. Bien que Bazaar travaille sur sa propre variante Tortue , elle n’existait pas encore en septembre 2008.
Ensuite, former les personnes clés à l'utilisation d'un système décentralisé pour leur travail.
Enfin, intégration au reste du système, tels que les systèmes de suivi des problèmes, le système de génération nocturne, le système de test automatisé, etc.
Votre principal problème sera que ce sont des GDS Distribués , et qu’ils nécessitent par conséquent un léger changement de mentalité. Une fois que les gens se seront habitués à l'idée, les détails techniques et les schémas d'utilisation se mettront en place, mais ne sous-estimez pas cet obstacle initial, en particulier dans une entreprise. N'oubliez pas que tous les problèmes sont des problèmes de personnes.
ddaa.myopenid.com l’a mentionné en passant, mais je pense que cela vaut la peine de le mentionner à nouveau: Bazaar peut lire et écrire dans des référentiels SVN distants. Cela signifie que vous pouvez utiliser Bazaar localement comme une preuve de concept, tandis que le reste de l'équipe utilise toujours Subversion.
EDIT: Presque tout l'outil a maintenant une possibilité d'interagir avec SVN, mais j'ai maintenant une expérience personnelle du fait que git svn fonctionne extrêmement bien. Je l'utilise depuis des mois, avec un hoquet minimal.
Il y a une bonne vidéo de Linus Torvalds sur git. Il est le créateur de Git, c’est ce qu’il promeut, mais dans la vidéo, il explique ce que sont les GDS distribués et pourquoi ils sont meilleurs que ceux centralisés. Il y a beaucoup de comparaisons entre git (mercurial est considéré comme OK) et cvs / svn / perforce. Le public a également posé des questions sur la migration vers la GDS distribuée.
J'ai trouvé ce matériel éclairant et je suis vendu à SCM distribué. Mais malgré les efforts de Linus, mon choix est mercurial. La raison est bitbucket.org, je l’ai trouvé mieux (plus généreux) que github.
Je dois dire ici un mot d’avertissement: Linus a un style plutôt 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 débutez dans les GDS distribués et pensez à passer de SVN.
Les systèmes de contrôle de version distribués (DVCS) résolvent différents problèmes par rapport aux VCS centralisés. Les comparer, c'est comme comparer des marteaux et des tournevis.
Lessystèmes VCS centralisés sont conçus de manière à ce qu'il y ait une seule source bénie et donc bon. Tous les développeurs travaillent (empruntent) à partir de cette source, puis ajoutent (engagent) leurs modifications, qui deviennent alors de la même manière bienheureuses. La seule différence réelle entre CVS, Subversion, ClearCase, Perforce, VisualSourceSafe et tous les autres CVCS réside dans le flux de travail, les performances et l'intégration proposés par chaque produit.
Lessystèmes VCS distribués sont conçus de manière à ce qu'un référentiel soit aussi performant qu'un autre. , et que les fusions d’un référentiel à un autre ne sont qu’une autre forme de communication. Toute valeur sémantique sur le référentiel auquel il faut faire confiance est imposée de l'extérieur par le processus et non par le logiciel lui-même.
Le vrai choix entre utiliser l’un ou l’autre type est l’organisation - si votre projet ou votre organisation souhaite un contrôle centralisé, un DVCS n’est donc pas un démarreur. Si vos développeurs sont censés travailler dans tout le pays / monde, sans connexions haut débit sécurisées vers un référentiel central, alors DVCS est probablement votre salut. Si vous avez besoin des deux, vous êtes fsck'd.
