BTW, je voudrais voir le pourcentage d'utilisation de différents systèmes DVCS.
sergiol
Réponses:
145
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].
Heya. Je veux juste que vous sachiez que cscvs est toujours utilisé pour exécuter les importations de code Launchpad, et j'ai fait sortir la version Canonical quand j'y travaillais.
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.
@gavenkoa, bazaar est intuitif pour les gens venant de SVN. Si vous venez de git, alors vous avez un modèle mental plus proche des fondements du bazar mais très, très loin de son interface. (... avoir une couche d'abstraction aussi épaisse entre les fondements et l'interface étant ce qui permet à bzr d'être amical avec les gens familiers avec le modèle SVN).
Charles Duffy
2
@CharlesDuffy Mercurial a également des noms intuitifs pour les commandes et non mortes (le développement de Bazaar a été bloqué il y a 2 ans et Canonical le rejette, oui, Git + github win jeu DVCS ). Je ne comprends jamais le schéma de nommage git, je préfère donc personnellement HG. Il est trop difficile de se battre avec des mecs amoureux de Git ((
gavenkoa
@gavenkoa, les noms de commandes de base de bzr correspondent aux SVN, donc encore une fois, je ne vois pas ce qui pourrait être peu intuitif à leur sujet (pour un utilisateur SVN). Oui, bien sûr, le développement est mort. Je ne dis pas que bzr est pratique à utiliser - seulement que la critique spécifique faite était hors de la base.
Charles Duffy
1
@gavenkoa, ... J'ai également été connu pour défendre certains aspects de BitKeeper, malgré une assez grande rancune contre les développeurs / propriétaires du logiciel (sa base est publiquement documentée ... même si Larry m'a appelé une fois pour décrire leur fin de quoi est arrivé, et j'accorde que je comprends maintenant les deux côtés). Ce n'est pas parce que je défends un SCM que je recommande aux gens de l'utiliser. :)
Charles Duffy
15
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).
FYI - bzr-svn est beaucoup plus capable que git-svn, en ce sens qu'il est bidirectionnel: je peux exécuter "bzr branch svn: // ...", et plus tard fusionner mes modifications sur le serveur svn - où elles sera stocké avec des métadonnées que d'autres clients bzr reconnaîtront.
Charles Duffy
2
Je suis un développeur hg et j'ai regardé un peu le design de Git. Je suis heureux de voir qu'ils traitent tous les deux l'historique de la seule manière raisonnable pour un paramètre distribué: à un niveau élevé, ils sont à la fois un graphique acyclique de commits et à un niveau inférieur, ils laissent tous les deux des commits de référence manifestent quels fichiers de référence (blobs dans Git ). Mercurial a des branches anonymes (qui, AFAIK n'existe pas dans Git), il a des branches marquées (tout comme les branches Git, mais pas de push / pull) et il a nommé des branches (le nom de la branche est enregistré dans commit - ce ne sont pas non plus dans Git).
Cette réponse serait améliorée par un résumé de ladite comparaison.
lindes
7
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.
Mercurial est vraiment à égalité avec Git. La performance n'est pas une grande différence. Mais bazar, est waaaay plus lent que Mercurial et Git.
Joshua Partogi
@jpartogi - Les performances de Bazaar se sont améliorées beaucoup plus rapidement que celles de ses concurrents, je serais donc prudent de faire ce genre d'affirmation - en particulier avec la refactorisation du stockage disponible en préversion dans les versions actuelles et devant devenir par défaut dans 2.0.
Charles Duffy
6
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.
Mozilla et Sun utilisent également Mercurial pour la même raison.
Joshua Partogi
2
bzr est également écrit en Python, il est en effet plus lent que hg mais avec une marge qui se rétrécit rapidement - et en tant qu'utilisateur à la fois de Bazaar et de Mercurial, je suis / fortement / en désaccord avec l'assertion "plus facile à apprendre".
Charles Duffy
1
Ils évoluent tous encore. J'ai décidé de commencer par Bazaar pour un DCVS parce que je pensais que c'était le plus simple (mais pas beaucoup) et Launchpad.net. C'était assez lent. Git sur OSX semble correct mais le support Windows est médiocre. Depuis que les projets Python et Google l'ont maintenant adopté, et à cause de TortoiseHg, je passe à Mercurial. Je pense que Mercurial gagne une masse critique sur Bazaar et y arrivera. Et Git fera son propre truc, toujours concentré sur Posix, donc ne sera jamais vraiment dominant.
Nick
5
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.
ces évaluations sont quelque peu dépassées, les nouvelles versions ont changé certains des inconvénients qui y sont énoncés.
hayalci
2
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.
Cela manque par conception - cp ne peut pas être ajouté sans créer un certain nombre de cas où il est difficile ou impossible d'être sûr de faire la bonne chose lors de la fusion entre une branche où une copie et des modifications se sont produites et une autre branche avec des modifications mais pas de copie .
Charles Duffy
Bien sûr, mais c'est quelque chose dont il faut être conscient - et ce serait une fonctionnalité très utile pour de nombreux cas d'utilisation (comme diviser un fichier en deux fichiers différents et conserver l'historique pour les deux). En fait, c'est la seule raison pour laquelle j'utilise toujours subversion pour certains projets - où la fusion n'est pas pertinente mais la copie ne l'est pas
Davide
2
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:
Git a la communauté la plus dynamique 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. 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.
Vous voulez dire «maintenant» très heureux, par opposition à «pas» très heureux, non?
Charles Duffy
Merci Charles! Bit un glissement freudien là :)
sh1mmer
1
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.
Mercurial est aussi simple que Bazaar, relativement rapide par rapport à git et a un bon support sur Bitbucket. Alors que pourriez-vous demander d'autre?
Joshua Partogi
1
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.
Pour mémoire, la page actuelle indique: "Depuis la version 1.6 de Bazaar, TortoiseBZR est inclus dans l'installateur officiel", il semble donc avoir mûri.
PhiLho
1
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.
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.
Il existe des différences très importantes entre CVS, SVN et VisualSourceSafe (pour ne citer que 3) qui ont un impact sérieux sur leur utilité - et ce ne sont pas seulement des problèmes de flux de travail et / ou d'intégration.
Murph
J'ai utilisé les trois, et techniquement vous avez raison, mais d'un point de vue de haut niveau, ma réponse est également valable. Le contrôle de version pour plus d'un seul développeur est un outil d'organisation; tant que l'outil répond aux besoins de l'organisation, c'est tout ce qui compte à long terme.
Réponses:
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].
la source
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.
la source
À 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.
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.
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).
la source
InfoQ a une belle comparaison .
la source
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.
la source
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:
la source
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.
la source
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.
la source
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:
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.
la source
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.
la source
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.
la source
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.
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.
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.
la source
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.
la source
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.la source
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
la source
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.
la source