Popularité de Mercurial/Git/Bazar vs qui recommander

Question

En passant par le nombre de questions sur ce site pour ces trois distribués, systèmes de contrôle de version, il semble que Git soit

1. est de plus en plus populaire, ou
2. est plus difficile (et donc nécessitant plus de questions), ou
3. a plus de fonctionnalités (et donc nécessitant plus de questions).

Ou plus probablement une combinaison des trois. (Disons que la popularité sur ce site correspond à la popularité.) Voici les chiffres:

 | Juin 2009 | Juillet 2010 | Juillet 2011 | Juillet 2012
-------------------------------------------------------
 [svn]| 2353 | 5323 | 9028 | 12687
 [git]| 726 | 3725 | 9225 | 17523
 [mercurial]| 169 | 1120 | 2765 | 4221
 [bazar]| 50 | 159 | 252 | 351

Il n'est pas entièrement satisfaisante de trois concurrents, mais largement équivalent open source de produits à choisir. Personnellement, j'utilise Git et je suis très bien avec les deux autres. Mais quand il s'agit de recommander un système sur les autres, je voudrais vous demander: pouvons-nous commencer à recommander un en toute sécurité?

Commentaires à partir de la mi-2009: La récente popularité historique de la Subversion est clairement reflété par le nombre de questions, en indiquant au moins un petit renversement de la balance vers Git à l'Mercurial ou Bazar.

Commentaires à partir de la mi-2010: Regardez cette énorme augmentation relative Mercurial numéros. Évidemment, seuls les deux points de données ne suffit pas de montrer une tendance, mais il semble que Git et Subversion sont largement ancrées, Mercurial a vu beaucoup de la croissance, et le Bazar est restée relativement calme.

Bref commentaire, à la mi-2011: Peut-on seulement appeler Git le gagnant? :) Non, j'accepte l'argument selon lequel le nombre de questions n'est pas l'équivalent de la popularité. Les numéros sont forts, bien que.

Answer 1

Mise À Jour De Novembre 2011:

Git est maintenant beaucoup plus mature par rapport à 2009:

• smart http est maintenant pris en charge, ce qui signifie que vous pouvez offrir à votre client protocole https pour tirer/clone et pousser, avec l'authentification en mesure d'interface avec un LDAP (important pour l'utilisateur dans une entreprise)
• Une mature couche d'autorisation existe maintenant avec Gitolite, ce qui signifie que vous pouvez fournir de l'isolement pour "confidentiel" référentiel (nouveau, important pour les grandes entreprises).
• Le support de Windows qui était déjà là en 2009, il est toujours aussi fort, et TortoiseGit est assez stable
• L'intégration avec l'IDE comme Eclipse est en cours (la plupart des projets Eclipse sont désormais sur GitHub)

Toutefois, l'installation de Git dans un environnement centralisé n'est pas trivial:
Voir "Contrôle de Version Distribué des Systèmes et de l'Entreprise - un Bon mélange?"

---

Un point constamment manquer:

ils sont différents dans leur nature.

• SVN est un système de RÉVISION (magasins de la branche et de marque pas cher copie seulement! Fusion de soutien n'est pas très efficace), et il est centralisé.
• Mercurial ou bazar FICHIER VCS (ils stockent les versions de fichiers), et distribué.
  Arne Babenhauserheide modifie que pour Mercurial en soulignant le modèle Historique, avec "fichier de manifeste et de la révision".
• Git, et c'est très dur à saisir, est un CONTENU VCS (il stocke delta du contenu, et non le fichier lui-même: deux fichiers avec le même contenu sera stocké qu'une seule fois)

Cela signifie que:

• si vous disposez d'une simple fusion de flux de travail, dans un seul emplacement de développement, bâton avec SVN
• si vous avez plusieurs endroits, un distribué des VCS est plus adapté.
• si vous avez un complexe de fusion de flux de travail, moderne VCS est mieux que SVN qui lutte pour garder la fusion d'informations aux bons endroits pendant des années. Il dépend alors de l'outils (Mercurial a une version plus avancée du support de Windows par exemple)
• si vous avez essentiellement fichier texte et pas trop gros fichiers binaires, Git est excellent, à condition que vous êtes conscient de ses limites.

Answer 2

En passant par le nombre de questions sur ce site pour ces trois distribués, systèmes de contrôle de version, il semble que Git soit

1. est de plus en plus populaire, ou
2. est plus difficile (et donc nécessitant plus de questions), ou
3. a plus de fonctionnalités (et donc nécessitant plus de questions).

1. Sur SCM de la popularité - voir la suite de StackOverflow question: il y a aucune popularité et l'utilisation de statistiques disponibles pour la Libre RCS/SCM/VCS systèmes?. Ici, nous avons des questions comme ce jeu d'ignorer les fichiers à utiliser pour un type spécifique de projet, qui sont SCM agnostique, mais ils sont invités pour Git (et à l'aide de git tag), parce que c'est ce que la personne qui a posé la question de l'utilisation.

2. Sur Git d'être plus difficile (et donc avoir plus de questions au sujet de sur DONC) -- certainement Git a plus raide de la courbe d'apprentissage. Il utilise également quelques (très) concepts uniques, comme la zone de transit (l'index), ou toutes les branches égales, qui sont responsables de sa puissance, mais il peut être difficile d'obtenir le droit au premier abord (surtout si l'on vient d'autres SCM). Aussi Git de l'INTERFACE utilisateur n'est pas complètement cohérent (même si ça va mieux), parce qu'il a été cultivé plutôt que développés; qui est responsable de sa puissance, mais pourrait conduire à sous-optimale de l'interface utilisateur.

3. Sur Git avoir plus de fonctionnalités -- vous avez pour vérifier la façon dont beaucoup de questions à propos de advanced / rare fonctionnalités de Git. Vous devez être conscient, cependant, que les projets open source emprunter des idées de l'un à l'autre, ou ont des caractéristiques similaires développées de manière indépendante: un exemple serait de trouver des bugs par bissectrice (la recherche) histoire de s'engager, qui a introduit le bug qui a été (autant que je sache) est développé d'abord dans Git, puis mis en œuvre en tant que plugin dans le Bazar, et la première extension et actuellement à la fonctionnalité de base de Mercurial. Une autre serait de interactif la sélection de fragments de changements de commettre, inspiré par Darcs comportement. Encore une autre serait de Git du bundle idée, emprunté à un concept similaire dans Mercurial.

4. Une autre possibilité encore de la source du plus grand nombre de question qui est peut-être le manque d'une bonne documentation... même si ça va mieux aujourd'hui avec Git Manuel de l'Utilisateur (distribué avec Git) et Git Community Book (trouvé sur Git page d'accueil). Il n'y a toujours cette persistance de mème que Git a pire documentation que, disons, la Subversion avec son Contrôle de Version avec Subversion (aussi connu comme svnbook) et Mercurial: The Definitive Guide (également connu en tant que hg-livre)... et les gens ne lisent pas la documentation avant de poser une question sur StackOverflow, parfois.

Il n'est pas entièrement satisfaisante de trois concurrents, mais largement équivalent open source de produits à choisir. Personnellement, j'utilise Git et je suis très bien avec les deux autres. Mais quand il s'agit de recommander un système sur les autres, je voudrais vous demander: pouvons-nous commencer à recommander un en toute sécurité?

Eh bien, Git et Mercurial ont été élaborées indépendamment de départ à peu près au même moment dans la réponse de la résiliation de licence gratuite pour BitKeeper pour une utilisation par les développeurs du noyau Linux, comme un remplacement pour elle. Subversion était hors de question de la centralisation de l'SCM, avec le manque de soutien (à l'époque) en base pour le suivi de fusion, ce qui a complètement inadapté pour la largement distribué modèle de développement du noyau Linux. Bazar était probablement trop lente (au moins à l'époque), et un peu sur centralisée côté (je suppose).

Git est plus puissant (à mon avis), Mercurial est plus simple (dans l'opinion de personnes) et un peu plus portable (Python); Git est scriptable, et est basé sur le modèle de données permettant indépendant reimplementations (voir, par exemple, JGit, git écrit en Java), tandis que l'Mercurial a liaisons Python pour écrire des extensions, et est largement basé sur l'API permettant le changement de référentiel sous-jacent format (revlog - revlog-ng)... mais c'est juste ma supposition. Ils remplissent légèrement différentes niches.

En plus de ne pas avoir un choix considéré comme une bonne chose? Nous avons KDE et nous avons GNOME et XFCE (et d'autres gestionnaires de fenêtres et de bureau envirionments); nous avons Emacs et Vim (et d'autres du programmeur éditeurs), nous nous sommes basé sur rpm (par exemple, Fedora Core, Mandriva, SuSE) et deb (Debian, Ubuntu) et tgz (Slackware) et la source (Gentoo) distributions, nous avons KWord, AbiWord et OpenOffice.org... et nous avons Git, Mercurial et le Bazar.

Answer 3

J’utilise et recommande mercurial

• au lieu de subversion car il prend en charge le développement distribué. Je peux travailler sur plusieurs machines et s’engager localement. Vous ne pouvez faire cela avec subversion, du moins pas sans sauts périlleux comme dépôts supplémentaires
• plutôt que de Bazar parce que la prise en charge de windows de Bazar est... Eh bien.
• plutôt que de git parce que c’est une) plus simple à apprendre et utiliser et b) windows prise en charge est beaucoup mieux

Answer 4

Dans mon expérience, à en juger par le nombre de questions sensiblement biaise la comparaison avec git et contre Mercurial. La raison en est double:

1. Jetez un oeil à l' hg update --help contre git checkout -h et git --help checkout. Avec Mercurial j'ai rarement trouvé des questions qui ne sont pas répondu par quelques regards à l'hg de l'aide.

2. http://mercurial.selenic.com/wiki - si vous avez besoin d'aide, vous trouverez probablement il ya, y compris de nombreux Trucs et Astuces: http://mercurial.selenic.com/wiki/TipsAndTricks

Answer 5

[REMARQUE: Avec la version de Subversion 1.7, le premier paragraphe de ma réponse ci-dessous est à jour, comme de la Subversion maintenant juste crée un seul ".svn" dossier dans le dossier de base, semblable aux autres maintenant.]

L'un des avantages de l'un des trois plus de la subversion, c'est qu'il ne crée pas un équivalent de ".svn" dossier dans chaque dossier du projet. Généralement, il existe un seul (".hg", ".bzr" ou ".git") dans le dossier de base. Rien que cela peut être une bonne raison pour utiliser l'un d'eux sur svn, même si vous utilisez un référentiel centralisé modèle. (Aparté: En fait, j'utilise souvent svk que mon client svn lors de l'utilisation d'un dépôt svn juste pour cette fonction (linux seulement si, svk est pas bon sur windows)).

Bien sûr, l'un des avantages de la subversion est que vous n'avez pas à vérifier-l'ensemble du projet, si vous avez seulement besoin de l'un de ses sous-dossiers.