Привет народ.

Знаю, тема много раз подымалась. Но нужна более свежее мнение по поводу выбора в использовании Git или Mercurial.

Необходимость выбора возникла из-за того, что компания Аtlassian (которая делает Jira) на своём хосте проектов прекращает поддержку Subversion (SVN) хранилищ. Соответственно, предлагает перейти на Git или Mercurial.
И теперь руководитель проекта требует сделать выбор. А так как, я все время проработал с SVN, иногда сталкивался с TFS и в начале своей карьеры видал MS SourceSafe, в общем, не имею практического использования ни Git, ни Mercurial, то выбор сделать сложно.

Поэтому прошу помочь и поделиться свежими впечатлениями.

Здравствуйте, MaLS, Вы писали:

MLS>И теперь руководитель проекта требует сделать выбор. А так как, я все время проработал с SVN, иногда сталкивался с TFS и в начале своей карьеры видал MS SourceSafe, в общем, не имею практического использования ни Git, ни Mercurial, то выбор сделать сложно.

Mercurial очень похож по командам на SVN, поэтому вам на него будет проще переходить. Git очень умный, но очень сложный и непривычный в управлении.

Здравствуйте, MaLS, Вы писали:

MLS>..., в общем, не имею практического использования ни Git, ни Mercurial, то выбор сделать сложно.
MLS>Поэтому прошу помочь и поделиться свежими впечатлениями.

Если в команде есть люди, предпочитающие одну из систем, брать её. Обе достаточно хороши для production. В крайнем случае, попробовать самому. Остальное скатится в holywar.

Здравствуйте, MaLS, Вы писали:

MLS>Поэтому прошу помочь и поделиться свежими впечатлениями.
Git. К сожалению, не работал с Hg, но есть большой опыт с SVN, в том числе и сложным CM. Также работал с cvs и perforce.
После работы с GIT пришёл к выводу, что он самый удобный из всех для команды с грамотным CM.

Здравствуйте, MaLS, Вы писали:

MLS>Поэтому прошу помочь и поделиться свежими впечатлениями.

Git, лично я в свое время повелся на кажущуюся простоту меркуриала, но потом все равно пришел к гиту. Меня обманули, гит оказался проще. Главное не начинать с командной строки если конечно она не является для вас родным домом.

Возьмите GitExtensions (я их даже под линуксом использую иногда) и поиграйтесь. Еще есть хорошая вводная статья

Автор(ы): Игорь Ткачев
Дата: 23.05.2011
Краткое введение в Git и Git Extensions.

IT. Осваивается за один день, главное понять принцип.

MLS>Знаю, тема много раз подымалась. Но нужна более свежее мнение по поводу выбора в использовании Git или Mercurial.
Я за Git. Вполне легко перешел с SVN.
Рекомендую сначала почитать принципы работы. Не стоит начинать с поиска прямых аналогий с SVN.

Здравствуйте, TimurSPB,

Подскажите, пожалуйста, у нас сейчас в одном хранилище храниться множество под проектов. Соответственно, используя SVN я локально получаю только нужную под-ветку и работаю с ней.
Как мне сказали, в Mercurial требует скачивать локально всё хранилище от корня. Для нас нет смысла перегонять весь огромный проект локально.
Таким образом в Git можно получить только часть хранилища, т.е. под-ветку?

Здравствуйте, MaLS, Вы писали:

MLS>Здравствуйте, TimurSPB,

MLS>Подскажите, пожалуйста, у нас сейчас в одном хранилище храниться множество под проектов. Соответственно, используя SVN я локально получаю только нужную под-ветку и работаю с ней.
MLS>Как мне сказали, в Mercurial требует скачивать локально всё хранилище от корня. Для нас нет смысла перегонять весь огромный проект локально.
Прочитай вводные статьи, там объясняется концепция репозитория git.
MLS>Таким образом в Git можно получить только часть хранилища, т.е. под-ветку?
Git следит за всем деревом исходников. Т.е. в вашем случаее нужно будет делать одно git хранилище под каждый проект чтобы получить только один проект. Если все проекты будут в одном репозитории, то придётся выкачиваться всё.

Здравствуйте, MaLS, Вы писали:

MLS>Соответственно, предлагает перейти на Git или Mercurial.

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

Bazaar тормозит.
Mercurial тормозит.
Git не тормозит.

Поэтому Git.

Mercurial технически лучше. Git распиарен и популярен. Поэтому лучше git.

Здравствуйте, vsb, Вы писали:

vsb>Mercurial технически лучше. Git распиарен и популярен. Поэтому лучше git.
У меня сложилось противоположное мнение. Технически git лучше продуман, поэтому невероятно гибкий и расширяемый.
Устройство git — очень простое, как и всё гениальное. И всё в подробностях описано в документации.
Как мне кажется, собственно поэтому он и пиарится легче. Где аналог gerrit для hg?

А кто нибудь может рассказать о Mercurial как он устроен, что там внутри творится?

Здравствуйте, MaLS, Вы писали:

MLS>Знаю, тема много раз подымалась. Но нужна более свежее мнение по поводу выбора в использовании Git или Mercurial.

За git, по следующим причинам:
1. Некоторые чрезвычайно удобные фишки, которые в конкурентах отсутствуют, в первую очередь это отдельное понятие "индекса", которое на порядки упрощает действия типа "я тут пол-файла наменял, разбираясь в этой хрени, а теперь мне это надо логически разделить на десять разных коммитов, причём часть действий пока не отправлять, потому что не уверен, а некоторые вообще только мои локальные хаки, их тем более не отправлять".
У аналогов в лучшем случае жалкая подделка. Аналогично, переформатирование предварительно сложенного локально набора коммитов перед их отправкой вверх — помогает предельно просто и ясно разделить разные изменения по ролям и сделать каждое из них однозначным и легко понятным.
2. Инфраструктурные средства для коллективной работы, такие, как gerrit. Аналоги хуже (например, универсальный review board значительно менее удобен). Впрочем, при Jira непонятно, на что это влияет.
3. В разы большее количество людей, уже знакомых с ним.

Здравствуйте, MaLS, Вы писали:

MLS>Поэтому прошу помочь и поделиться свежими впечатлениями.

Git, по моему мнению, чрезмерно черезжопен и обладает топой яростных и шумных фанатов. Mercurial -- опять же, по моему мнению -- прост и понятен; коммьюнити не такое большое и не так популярен.

Я за Hg.

Здравствуйте, MaLS, Вы писали:

MLS>Привет народ.

MLS>Знаю, тема много раз подымалась. Но нужна более свежее мнение по поводу выбора в использовании Git или Mercurial.

MLS>Необходимость выбора возникла из-за того, что компания Аtlassian (которая делает Jira) на своём хосте проектов прекращает поддержку Subversion (SVN) хранилищ. Соответственно, предлагает перейти на Git или Mercurial.
MLS>И теперь руководитель проекта требует сделать выбор. А так как, я все время проработал с SVN, иногда сталкивался с TFS и в начале своей карьеры видал MS SourceSafe, в общем, не имею практического использования ни Git, ни Mercurial, то выбор сделать сложно.

MLS>Поэтому прошу помочь и поделиться свежими впечатлениями.

меркуриал более легковесен в установке на венду чем гит, установка гита на венде тянет установку MSys, и если вы ставите отдельный пакет типа TortoiseGit — то это еще 1 мсис к уже имеющимся, и тутначинаются танцы с конкуренцией мсисов ранее установленых продуктов. меркуриал за счет полной питоновости совершенно прозрачен и легок для установки везде.

помимо этого для меня просто эпичен и незаменин плагин mq и в полка в мекруриале. Собственно за них я "ртуть" и полюбил и свн анафеме предал.
аналоги их наверное есть в гите и вообще в линях, но меркуриал их таскает с собой как интегрированные а в TortoiseGit и в базаре я их не нашел.

сборки и базара и гита для венды частенько выдают ошибки и падения на венде. от меркуриала видел весьма стабильную, по сравнению с теми, работу.

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

Здравствуйте, alexraynepe196, Вы писали:

A>меркуриал в теории имеет средства синхронизации с свн, на практике они походу работают только под линями, а под венду чтобы соотвествующий плагин поставить надо попотеть. он может нормально затягивать из меркуриала но из свн — наилоегчайшее что я нашел скрипты hgsvn. он они конечно убоги, и требуют большой работы еще.
Пользуюсь hgsubversion больше 2х лет. Практически абсолютная интеграция. И я не встретил никаких серьезных проблем за это время.
Ты работаешь с репозиторием svn как будто он меркуриаловский. Единственное что, это невозможность мержа из меркуриала и hg rebase --svn после пула. Но причины обоих ограничений понятны и, в принципе, не доставляют проблем вообще.

СУВ, Aikin

Здравствуйте, MaLS, Вы писали:

MLS>Здравствуйте, TimurSPB,

MLS>Подскажите, пожалуйста, у нас сейчас в одном хранилище храниться множество под проектов. Соответственно, используя SVN я локально получаю только нужную под-ветку и работаю с ней.
MLS>Как мне сказали, в Mercurial требует скачивать локально всё хранилище от корня. Для нас нет смысла перегонять весь огромный проект локально.
MLS>Таким образом в Git можно получить только часть хранилища, т.е. под-ветку?

Есть расширение hg subrepository, git submodules
чем-то похоже на externals в svn но не такие удобные.

Работал с обеими. С Mercurial мне работать комфортнее, так что рекомендовал бы его.

Первое впечатление о GIT, кусок Г. Не позволяет прозрачно отследить историю изменения файла. Родной клиент GIT это каждый коммит == русская рулетка.

Здравствуйте, minorlogic, Вы писали:

M>Первое впечатление о GIT, кусок Г. Не позволяет прозрачно отследить историю изменения файла.

Что значит прозрачно? git {log|annotate|blame} $file — чем плохо?

M> Родной клиент GIT это каждый коммит == русская рулетка.

Не понимаю. Никаких проблем с коммитами в родном клиенте.

Здравствуйте, netch80, Вы писали:

N>Здравствуйте, minorlogic, Вы писали:

M>>Первое впечатление о GIT, кусок Г. Не позволяет прозрачно отследить историю изменения файла.

N>Что значит прозрачно? git {log|annotate|blame} $file — чем плохо?

Плохо тем , что я понятия не имею что ты написал. Если для этого надо изучать 3х томный мануал , то в баню всю систему.

M>> Родной клиент GIT это каждый коммит == русская рулетка.

N>Не понимаю. Никаких проблем с коммитами в родном клиенте.

Не шути, родной клиент это издевательсво над здравым смыслом. Такие операции , как отследить историю изменений файла , простые ресолвы конфликтов , синхронизация с анешним хранилищем отсутствуют. Это просто эпик фейл