Популярность Git/Mercurial/Bazaar против которой рекомендуется

Судя по количеству вопросов на этом сайте для этих трех распределенных систем контроля версий, похоже, что Git либо

является более популярным, или
сложнее (следовательно, требует больше вопросов), или
имеет больше возможностей (следовательно, требует больше вопросов).

Или, скорее всего, сочетание трех. (Допустим, популярность на этом сайте приравнивается к популярности в целом.) Вот цифры:

Неудовлетворительно иметь на выбор три конкурирующих, но в значительной степени эквивалентных продукта с открытым исходным кодом. Лично я использую Git, и я в порядке с двумя другими. Но когда дело доходит до рекомендации одной системы по сравнению с другими, я хотел бы спросить: можем ли мы начать рекомендовать одну безопасную еще?

Комментарии с середины 2009 года. Недавняя историческая популярность Subversion четко отражена в количестве вопросов, указывающих, по крайней мере, на небольшое изменение шкалы в сторону Git над Mercurial или Bazaar.

Комментарии с середины 2010 года: посмотрите на это огромное относительное увеличение численности ртути. Очевидно, что только двух точек данных недостаточно, чтобы показать тенденцию, но похоже, что Git и Subversion в значительной степени укоренились, Mercurial значительно выросла, а Bazaar остается относительно спокойным.

Краткий комментарий, середина 2011 года: можно ли назвать Git победителем? :) Нет, я принимаю аргумент, что количество вопросов не эквивалентно популярности. Числа, конечно, сильны, хотя.

Коды для воспроизведения вышеуказанных сюжетов:

import datetime as dt
import matplotlib.pyplot as plt


dates = [
    "01/06/2009",
    "01/07/2010",
    "01/07/2011",
    "01/07/2012",
    "01/07/2013",
    "01/07/2014",
    "01/07/2015",
    "01/07/2016",
    "01/06/2017",
    "28/08/2018",
    "27/05/2019"
]
x = [dt.datetime.strptime(d, "%d/%m/%Y").date() for d in dates]

git = [726, 3725, 9225, 17523, 27862, 41478, 55315, 71056, 86958, 102362, 110970]
svn = [2353, 5323, 9028, 12687, 15587, 18846, 21209, 23037, 24692, 25525, 25868]
mercurial = [169, 1120, 2765, 4221, 5230, 6030, 6651, 7134, 7524, 7765, 7894]
bazaar = [50, 159, 252, 351, 425, 483, 506, 525, 534, 539, 544]

ax = plt.gca()

ax.grid()
plt.plot(x, git, label="[git]")
plt.plot(x, svn, label="[svn]")
plt.plot(x, mercurial, label="[mercurial]")
plt.plot(x, bazaar, label="[bazaar]")
plt.gcf().autofmt_xdate()
plt.ylabel("number of tags on stackoverflow")
plt.ylim(0)

plt.legend()

# plt.show()
plt.savefig("comparison.png", transparent=True, bbox_inches="tight")

import datetime as dt
import matplotlib.pyplot as plt


dates = [
    "01/06/2009",
    "01/07/2010",
    "01/07/2011",
    "01/07/2012",
    "01/07/2013",
    "01/07/2014",
    "01/07/2015",
    "01/07/2016",
    "01/06/2017",
    "28/08/2018",
    "27/05/2019"
]
x = [dt.datetime.strptime(d, "%d/%m/%Y").date() for d in dates]

git = [726, 3725, 9225, 17523, 27862, 41478, 55315, 71056, 86958, 102362, 110970]
svn = [2353, 5323, 9028, 12687, 15587, 18846, 21209, 23037, 24692, 25525, 25868]
mrc = [169, 1120, 2765, 4221, 5230, 6030, 6651, 7134, 7524, 7765, 7894]
bzr = [50, 159, 252, 351, 425, 483, 506, 525, 534, 539, 544]

n = len(dates)
intervals = [x[i+1] - x[i] for i in range(n-1)]
git_per_day = [(git[i+1] - git[i]) / intervals[i].days for i in range(n-1)]
svn_per_day = [(svn[i+1] - svn[i]) / intervals[i].days for i in range(n-1)]
mrc_per_day = [(mrc[i+1] - mrc[i]) / intervals[i].days for i in range(n-1)]
bzr_per_day = [(bzr[i+1] - bzr[i]) / intervals[i].days for i in range(n-1)]

ii = [0] + [val for val in range(1, n-1) for _ in (0, 1)] + [n-1]
jj = [val for val in range(n-1) for _ in (0, 1)]

ax = plt.gca()
ax.grid()

plt.plot([x[i] for i in ii], [git_per_day[j] for j in jj], label="[git]")
plt.plot([x[i] for i in ii], [svn_per_day[j] for j in jj], label="[svn]")
plt.plot([x[i] for i in ii], [mrc_per_day[j] for j in jj], label="[mercurial]")
plt.plot([x[i] for i in ii], [bzr_per_day[j] for j in jj], label="[bazaar]")

plt.gcf().autofmt_xdate()
plt.ylabel("average daily tags on stackoverflow")
plt.legend()
plt.ylim(0)

# plt.show()
plt.savefig("comparison-daily.png", transparent=True, bbox_inches="tight")

Ответы

Ответ 1

Обновление ноября 2011 года:

Git теперь намного более зрелый по сравнению с 2009 годом:

Теперь поддерживается интеллектуальный http, что означает, что вы можете предложить вашему клиенту протокол https для извлечения/клонирования и проталкивания с аутентификацией, способной взаимодействовать с LDAP (важно для пользователя на предприятии)
Теперь в Gitolite существует зрелый уровень авторизации, что означает, что вы можете обеспечить изоляцию для "конфиденциального" хранилища (опять же, важно для крупных компаний).
Поддержка Windows, которая уже была в 2009 году, по-прежнему сильна, а TortoiseGit довольно стабильна
Идет интеграция с IDE, такой как Eclipse (большинство проектов Eclipse сейчас находятся на GitHub)

Однако установка Git в централизованной среде не тривиальна:
См. " Распределенные системы контроля версий и предприятие - хорошее сочетание? "

Постоянно упускается один момент:

они разные по своей природе.

SVN - это система REVISION (она хранит ветки и метки только через дешевое копирование! Поддержка слияния не очень эффективна) и является централизованной.
Mercurial или базар являются FILE VCS (они хранят версии файлов) и распространяются.
Арне Бабенхаузерхайде вносит поправки в Mercurial, указывая, что модель Mercurials History отслеживает изменения содержимого, а пути файлов повторно используются на уровне хранилища для оптимизации доступа к файловой системе.
Git, и это очень трудно понять, это CONTENT VCS (он хранит дельту контента, а не сам файл: два файла с одинаковым контентом будут сохранены только один раз)

Это означает:

если у вас есть простой рабочий процесс слияния, в одном месте разработки придерживайтесь SVN
если у вас есть несколько мест разработки, распределенная VCS более адаптирована.
если у вас сложный рабочий процесс слияния, любая современная VCS лучше, чем SVN, которая борется за то, чтобы хранить информацию о слиянии в нужных местах в течение многих лет. Это зависит от инструментов (например, Mercurial имеет более продвинутую поддержку Windows)
если у вас есть в основном текстовый файл и не слишком большие двоичные файлы, Git отлично работает, если вы знаете его ограничения.

Ответ 2

По количеству вопросов на этом сайте для этих трех распределенных систем управления версиями, похоже, Git либо

является более популярным, или

сложнее (следовательно, требуется больше вопросов), или

имеет больше возможностей (поэтому требуется больше вопросов).

О популярности SCM - см. следующий вопрос StackOverflow: Есть ли статистика популярности/использования, доступная для Free RCS/SCM/VCS системы?. Здесь у нас есть такие вопросы, как набор игнорируемых файлов для конкретного проекта, которые являются агностиками SCM, но запрашиваются Git (и используют тег git), потому что это тот, кто задал вопрос.
Git сложнее (и поэтому имеет больше вопросов о SO) - конечно Git имеет более крутую кривую обучения. Он также использует несколько (совершенно) уникальных концепций, таких как область постановки (индекс) или все ветки, равные, которые отвечают за ее мощность, но могут быть трудно получить сразу (особенно если кто-то приходит из другого SCM), Кроме того, пользовательский интерфейс Git не полностью согласован (хотя он становится лучше), потому что он вырос, а не развит; который отвечает за его мощность, но может привести к субоптимальному пользовательскому интерфейсу.
В Git больше функций вам нужно будет проверить, сколько вопросов SO связано с продвинутыми/необычными функциями Git. Однако вы должны знать, что проекты с открытым исходным кодом заимствуют идеи друг от друга или имеют схожие функции, разработанные независимо: один пример - поиск ошибок путем дебитации (поиска) истории для фиксации, которая ввела ошибку, которая была (насколько мне известно) сначала в Git, а затем реализована как плагин в Bazaar, а также первая расширительная и в настоящее время основная функциональность в Mercurial. Другим будет интерактивный выбор фрагментов изменений для фиксации, вдохновленный поведением Даркса. Еще одна идея Git bundle, взятая из аналогичной концепции в Mercurial.
Еще одна возможность источника большего числа вопросов SO может быть отсутствием хорошей документации... хотя теперь она становится лучше с Git Руководство пользователя (распространяется с помощью Git) и Git Community Book (найдено на Git домашняя страница). Тем не менее, существует постоянный mem, что Git имеет хуже документации, чем, скажем, Subversion с Version Control with Subversion (также известный как svnbook) и Mercurial: The Definitive Guide (также известный как hg-book)... и люди не читают документацию, прежде чем задавать вопрос о StackOverflow, иногда.

Это не совсем удовлетворительно, когда есть три конкурирующих, но в основном эквивалентных продукта с открытым исходным кодом. Лично я использую Git, и я в порядке с двумя другими. Но когда речь заходит о том, чтобы рекомендовать одну систему над другими, я хотел бы спросить: можем ли мы еще раз рекомендовать одну из них?

Хорошо, Git и Mercurial были разработаны независимо, начиная примерно в одно и то же время в ответ на прекращение бесплатной лицензии для BitKeeper для использования разработчиками ядра Linux, в качестве замены для нее. Subversion не могло быть и речи, поскольку централизованный SCM, с отсутствием поддержки (тогда) в ядре для отслеживания слияния; это сделало его совершенно непригодным для широко распространенной модели разработки ядра Linux. Базар был, вероятно, слишком медленным (по крайней мере, тогда), и немного на централизованной стороне (я думаю).

Git более мощный (на мой взгляд), Mercurial проще (по мнению людей) и немного более портативен (Python); Git является сценарием и основан на модели данных, позволяющей выполнять независимые повторные реализации (см., например, JGit, Git, написанные на Java), в то время как Mercurial имеет привязки Python для написания расширений и в основном основан на API, позволяющем изменять базовый формат репозитория (revlog - revlog-ng)... но это только мое предположение. Они заполняют несколько разных ниш.

Кроме того, выбор не считается хорошим? У нас есть KDE, и у нас есть GNOME и XFCE (и другие оконные менеджеры и настольные приложения); у нас есть Emacs и Vim (и другие редакторы программистов); у нас есть rpm-based (например, Fedora Core, Mandriva, SuSE) и deb-based (Debian, Ubuntu) и tgz-based (Slackware) и исходные (Gentoo) дистрибутивы; у нас есть KWord, AbiWord и OpenOffice.org... и у нас есть Git, Mercurial и Bazaar.

Ответ 3

Я использую и рекомендую mercurial

а не subversion, поскольку он поддерживает распределенную разработку. Я могу работать на нескольких машинах и совершать локально. Вы не можете сделать это с помощью subversion, по крайней мере, не без кувырок, как дополнительные репозитории.
а не базар, потому что поддержка базарных окон... ну.
а не git, потому что это: a) проще узнать и использовать, и b) поддержка окон намного лучше

Ответ 4

По моему опыту, судя по количеству вопросов, заметно искажается сравнение с мерзавцем и против Mercurial. Причина двоякая:

Посмотрите на hg update --help сравнении с git checkout -h и git --help checkout. С Mercurial я редко находил вопросы, на которые нет ответа несколькими взглядами на hg help.
Проверьте Mercurial Wiki - если вам нужна помощь, вы, скорее всего, найдете ее там, включая множество подсказок и хитростей: http://mercurial-scm.org/wiki/TipsAndTricks

Ответ 5

[ПРИМЕЧАНИЕ. С выпуском Subversion 1.7 первый абзац в моем ответе ниже устарел, так как теперь Subversion создает только одну папку ".svn" в базовой папке, аналогичную другим.]

Одним из преимуществ любого из трех подделок является то, что он не создает эквивалент ".svn" в каждой папке проекта. Обычно имеет только одну ( ".hg", ".bzr" или ".git" ) в базовой папке. Это само по себе может быть хорошей причиной для использования одного из них по svn, даже если вы используете модель централизованного репозитория. (На самом деле, я часто использую svk как мой svn-клиент при использовании репозитория svn только для этой функции (только для Linux, svk не хорош для окон)).

Конечно, одно преимущество подрывной деятельности - вам не нужно проверять весь проект, если вам нужна только одна из его подпапок.

Ответ 6

Canonical (Ubuntu) отслеживает использование пакета программного обеспечения для своего дистрибутива, поэтому нет необходимости полагаться на количество проблем в Stack Exchange для измерения популярности. Однако, как отмечали другие, это только треки пользователей Ubuntu и Canonical (Ubuntu) использует и рекомендует bzr (выборочное смещение). Тем не менее...

            2011    2011    2011           
Package     Aug 3   Sep 29  Dec 9   Change 
------      ------  ------  ------  ------ 
git-core    3647    3402    3236    -11%   
bzr         4975    5286    6070    +22%   
mercurial   3411    3387    3461     +1%

Снижение голосов для пакета git -core заставляет меня думать, что я сделал что-то не так, как grep изменил неправильное имя пакета из таблицы популярности ubuntu. Или, может быть, даже это "подсчет голосов" связано с установками, а не с фактическим использованием программного обеспечения.

Вот некоторые исторические данные для трендов. Я использовал статистику <install>, а не <vote> из Ubuntu в этой таблице, но в 2011 году она показывает всплеск роста в Bazaar и Mercurial. Тем не менее, bzr отставал от git в 2011 году, но недавняя статистика для 2011 показывает, что он прошел git в общих установленных экземплярах (на Ubuntu).

        June    Aug     Dec     Growth  Oct   Growth
        2010    2011    2011            2013 
----    -----   ----    ----    ------  ----  ------
git      94k    159k    171k      80%   165k   -3.5%
bzr      52k    121k    135k     160%   170k   26.0%
hg       36k     68k     75k     110%    95k   26.7%

Discalaimer: я использовал bzr на Ubuntu до 2012 года, когда работал над командами, которые использовали git исключительно. bzr играет хорошо со всеми другими VCS, позволяя использовать последовательный, интуитивно понятный синтаксис командной строки bzr. Мой переход на git был для социальных, а не технических причин.

Ответ 7

Поскольку происхождение социального кодирования с Git на GitHub, Git, похоже, привлекло много последователей.

Ответ 8

Ну, причина в том, что git так много пользователей, что ядро Linux использует его, поэтому, если вы хотите заниматься разработкой Linux, вы используете git.

Поскольку так много людей связано с git, я бы рекомендовал использовать git, просто из-за большей базы пользователей. Фактически, цифры, которые вы показываете выше, являются явным признаком этого.

Как и в случае с трудностями, все управление версиями сложно, особенно распределенный. SVN и CVS были не совсем легкими (для меня как минимум) на первый взгляд. Это всего лишь часть необходимой кривой обучения для использования в системе управления версиями.

EDIT: Поскольку вы добавили ссылку на subversion, я подумал, что я бы обратился к ней. Я думаю, что большинство людей будут использовать svn, потому что для него есть всевозможные графические интерфейсы. В общем, люди ненавидят использовать командную строку, включая некоторых разработчиков. git обычно не работает очень хорошо в Windows (или, по крайней мере, не так легко). Поскольку многие люди находятся в Windows, это убивает число потенциальных пользователей.

Кроме того, я думаю, что концепции SVN немного легче понять, поскольку svn использует центральный репозиторий, а не распределенную систему. Легче понять: "Вот большая гора кода, пожалуйста, добавьте здесь свой код", чем "Вот какой-то код, мой может отличаться от его, его от нее, но вы можете добавить что-то, если хотите".

По моему мнению, svn имеет гораздо лучшую систему документации. Документация git ориентирована на немного более высокий уровень знаний (программы, а не на информацию программистов), и поэтому имеет смысл после использования системы, но при первом запуске она просто выглядит как кучка gobbeldy-gook.

В целом, я думаю, что svn является и будет всегда более распространенным, потому что его общие операционные концепции легче понять, инструменты просты в использовании, и он имеет прекрасную поддержку в Windows.

Позвольте мне закончить мои последние два цента, хотя и говорю, что я предпочитаю git, потому что я думаю, что он намного более мощный, чем любая другая система, которую я использовал. Восхождение на кривую обучения определенно окупается, как только вы начинаете понимать программу лучше.

Ответ 9

Отметьте следующую ссылку на опрос по теме:

http://www.debian-administration.org/polls/160

Ответ 10

Интересное сообщение в блоге от Eric Sink о них всех.

Ответ 11

Я обычно не публикую, но..

Я пробовал git, bzr и несколько других, я забыл и нашел, что у bzr есть очень очень слабая точка. Для больших файлов он настаивает на загрузке всего файла в память. Это создает проблемы для больших двоичных файлов.

Git было намного лучше в этом отношении. Что касается трудности. Я использую git в окнах из git bash. Работает отлично и учится менее чем за неделю (включая фактическую работу и эксперименты с другими VCS).