Git / Mercurial (hg) мнение - PullRequest
       1

Git / Mercurial (hg) мнение

25 голосов
/ 27 марта 2010

Во-первых, позвольте мне сказать, что я не профессиональный программист, но инженер, который нуждался в этом и должен был учиться. Я всегда работал один, так что это были только я и мои семь разделенных личностей ... и мы хорошо работали в команде :) Большая часть моей работы сделана на C / Fortran / Matlab, и до сих пор я изучал git для справиться со всем этим Однако, хотя у меня не было неразрешимых проблем с этим, я никогда не был «так» счастлив этим ... для всего, что я не могу сделать, я должен искать книгу. И в течение некоторого времени я слышал много хорошего о Mercurial.
Теперь моему коллеге придется поработать со мной над проектом (мне его почти жаль), и он начал изучать Mercurial (говорит, что ему это нравится больше), и я сам рассматриваю этот вариант.

Мы работаем почти исключительно на платформе Windows (хотя я относительно неплохо справляюсь с использованием инструментов Unix и всего, что происходит в этой части мира).

Итак, мне было интересно, в описанном сценарии, какие проблемы можно ожидать с коммутатором. Я слышал, что Mercurial более удобен для пользователей Windows, в отношении пользовательских интерфейсов.

Как это работает с репозиториями? Создает ли он их так же, как это делает git (только один подкаталог в рабочем каталоге), и я могу просто скопировать весь каталог проекта (включая git repo) и просто перенести их куда-нибудь, не задумываясь? (Мне очень понравилось, когда я выбирал git / svn).

Есть ли хорошие книги, которые вы можете порекомендовать (что-то вроде Pro Git, только для Mercurial).

Каковы хорошие способы внедрения Mercurial в Visual Studio / GVim для Windows или в Windows Explorer, чтобы я мог работать относительно легко (я хотел бы избегать использования командной строки для всего, что с ней связано, как в git shell).

Есть ли что-то еще, о чем я должен знать (пожалуйста, не задавайте мне другие вопросы ... они просто дают мне тонну информации, и я не уверен, что мне следует принять как важно, а что не учитывать). Я пытаюсь сократить время, так как я не могу тратить все это время на перезапуск Mercurial, как я это делал для git.

Я также слышал, что git - это проект c, а mercurial - это python ... есть ли заметная разница в скорости? мерзавец был довольно быстр ... я столкнусь с некоторым ожиданием во время работы.

Примечание: все мои проекты, скажем, среднего размера ... в основном числовые симуляции ... 10-15000 строк (средний размер?)

Ответы [ 10 ]

18 голосов
/ 27 марта 2010

Git Pros:

  • Сверхбыстрый (хорошо масштабируется для очень крупных проектов)
  • Чрезвычайная гибкость
  • Инструменты C, которые хорошо вписываются в философию Unix

Git Минусы:

  • Крутая кривая обучения
  • Инструменты с графическим интерфейсом существуют, но (IMO) не настолько прочны

HG Плюсы:

  • Очень быстро (хотя и не так быстро, как GIT) - задержки не должны быть серьезной проблемой в проекте длиной 15-20 тыс. Строк
  • Хорошие инструменты с графическим интерфейсом, даже в Windows (TortoiseHg хорош и очень зрел, а также есть и другие)
  • Хорошо документировано, и даже версия для Windows имеет приятный графический интерфейс с графическим представлением наборов изменений
  • Чуть легче учиться, чем в GIT (imo)

HG Минусы:

  • Несколько медленнее, чем git
  • Возможно, чуть менее гибкий

Есть и другие существенные различия, но они наиболее значимы в моем представлении. Честно говоря, если бы я в основном работал над Windows, я бы, наверное, пошел с Mercurial.

16 голосов
/ 27 марта 2010

Во-первых, позвольте мне сказать, что я не профессиональный программист, но инженер, который нуждался в этом и должен был учиться.

Инженер здесь тоже. Я использовал Mercurial, Subversion, BitKeeper и CVS. Еще не добрался до Git.

Я слышал, что hg более удобен для пользователей Windows, в отношении пользовательских интерфейсов.

Не уверен, что здесь имелось ввиду, Git и Mercurial оба являются инструментами командной строки.

Как это работает с репозиториями?

Это распределенная система управления версиями (DVCS), как и Git.

Создает ли он их так же, как это делает git (только один подкаталог в рабочем каталоге), и я могу просто скопировать весь каталог проекта (включая репозиторий git) и просто перенести их куда-нибудь, не задумываясь? (Мне очень понравилось, когда я выбирал git / svn).

Да. Репозиторий Mercurial находится в каталоге .hg в рабочем каталоге. Кроме того, Mercurial имеет систему именования в своем хранилище для предотвращения конфликтов имен файлов, если вы используете ее с нечувствительной к регистру файловой системой, такой как FAT, NTFS или HFS +.

Есть ли какие-нибудь хорошие книги, которые вы можете порекомендовать (что-то вроде Pro Git, только для Hg).

Я бы порекомендовал веб-сайт: https://www.mercurial -scm.org / guide

Каковы хорошие способы внедрения hg в Visual Studio / GVim для Windows или в Windows Explorer, чтобы я мог работать относительно легко (я хотел бы избегать использования командной строки для всего, что с ней связано, как в git shell).

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

Я также слышал, что git - это c-проект, а mercurial - это python ... есть ли заметная разница в скорости? мерзавец был довольно быстр ... я столкнусь с некоторым ожиданием во время работы.

Mercurial довольно чертовски быстр. Я не знаю, как это складывается с Git, но это намного быстрее, чем Subversion.

Примечание: все мои проекты, скажем, среднего размера ... в основном числовые симуляции ... 10-15000 строк (средний размер?)

Звучит как мои вещи. Конечно, не считая необработанных данных.

и не по теме ...

Большая часть моей работы сделана на C / Fortran / Matlab, и до сих пор я учил git управлять всем этим.

Я недавно перешел из Matlab в Python ...

  • Нет необходимости беспокоиться о лицензии и обслуживании.
  • Это все с открытым исходным кодом.
  • NumPy, SciPy и MatPlotLib делают большую часть того, что мне нужно.
  • Я могу взять свой код и легко интегрировать его с кодом на основе сокетов для общения с измерительными приборами. (Мне нравится, когда я могу генерировать сигнал, загружать его в генератор функций, ждать, пока сработает область, захватить его трассировку и статистику и поместить все это в цикл.)
  • Я могу интегрировать его с PyGtk, PyQt, веб-сервером, генератором PDF (ReportLib) и, кто знает, что еще.
  • Я могу отправить свой код на Python без необходимости лицензирования или лицензионных отчислений.
  • Python лучше для дисциплинированной разработки программного обеспечения, чем Matlab. Материал Matlab «одна функция на файл и один каталог на класс» безумен.
  • Python легче расширять с помощью кода на C и C ++. Библиотеки там лучше.

Просто мысль.

ГОДА ПОЗДНЕЕ РЕДАКТИРОВАНИЕ: Существует инструмент Mac DVCS под названием SourceTree , которым я очень доволен. Он поддерживает как Git, так и Mercurial, и доступен бесплатно в App Store.

9 голосов
/ 27 марта 2010

С точки зрения ваших очков:

  • Mercurial лучше для пользователей Windows - проще в установке, без дурацкого повреждения терминала :) - в основном, больше с меньшими затратами работы, имхо.
  • Git работает быстрее, чем Mercurial - тесты показывают это. Это, как вы сказали, потому что Git написан на C. Я не считаю Mercurial медленным , если честно.
  • Если ваш друг использует Mercurial, используйте Mercurial для этого проекта. Они очень похожи по своему базовому интерфейсу и функциональности - я могу очень легко получить Hg из Git.
  • Возможно, я ошибаюсь, но я считаю, что Git имеет большее сообщество пользователей, вероятно, из-за его использования ядром Linux.
  • Спасибо комментаторам: в Git есть Github - один из лучших сайтов для размещения кода когда-либо . (Поверь мне!)
  • Многие громкие проекты используют Git (ядро, Rails, JQuery) - страница репозиториев Github интересна - я поражен тем, сколько проектов я распознаю и использую ежедневно Git!
  • У Mercurial есть действительно очень хорошее руководство, написанное Джоэлем Спольски на hginit.com . Это лучшее руководство по управлению исходным кодом, которое я когда-либо читал! :)
8 голосов
/ 09 июня 2011

Я бы хотел кое-что сказать по поводу тестов. Есть поговорка, которая мне нравится: «Никогда не доверяй эталону, который сам не притворялся»: -)

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

Видите ли, у Git есть два формата репозитория: один очень быстрый для выполнения коммитов, но он крайне неэффективен, а по мере увеличения размера репозитория другие операции замедляются. Вот почему они добавили второй формат репозитория, который очищает неиспользуемые файлы и сохраняет данные более эффективно, тем самым уменьшая занимаемую площадь и повышая производительность. Это то, что делает команда "git-gc" ("gc == сборщик мусора").

Так угадайте, что происходит? Когда бенчмарк Git сообщает о быстром времени фиксации, то есть с одним форматом, и когда они сообщают о небольшом месте или некоторой быстрой операции, то это о втором формате. И ни один тест не показывает стоимость цикла сбора мусора. В результате Git выглядит быстрее.

Заметьте, я не говорю, что Git работает медленно. Но я думаю, что тесты на сайте Git переоценивают его скорость, и, в частности, я не уверен, что Git на самом деле быстрее, чем Mercurial.

Mercurial использует эффективный формат, который дает вам время фиксации «почти» так же быстро, как формат Git «толстый», а размер диска «почти» такой же маленький, как формат «Git» slim », без стоимости мусора. промежуточный цикл сбора.

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

6 голосов
/ 30 марта 2010

Мой переход от Git к Mercurial стал намного проще после прочтения Руководство по ветвлению в Mercurial , которое также относится к способу ветвления в Git.

Если у вас есть IIS 7, вы можете легко настроить сервер Mercurial: Настроить сервер Mercurial под IIS7 в Windows Server 2008 R2 , и вы можете легко найти руководства, используя IIS 6 или Apache2. Конечно, для быстрой синхронизации hg serve неоценим: , используя «hg serve» для изменения

Интеграция Visual Studio:

Бесплатный хостинг:

Руководства и учебные пособия можно начать с Mercurial wiki .

6 голосов
/ 27 марта 2010

Я возьму это по пунктам ...

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

Mercurial имел преимущество в Windows, но я думаю, что Git там тоже улучшился, так что, вероятно, это не очень хороший дифференциатор.

Что касается пользовательских интерфейсов, вы можете подумать, что TortoiseHg (интеграция с оболочкой Windows, которую вы упомянули) будет полезен, если вам не нравится командная строка. Работая на Windows, я не виню вас. :)

Mercurial создает репозитории так же, как это делает Git: один скрытый подкаталог под корневым каталогом. Вы можете перемещать его по своему усмотрению (положить на флешку, взять в другом месте и т. Д.) Почему это было проблемой с SVN?

Я счастлив сказать, что, рассматривая Hg как инструмент для выполнения работы, я не чувствовал необходимости искать «хорошую книгу». Возможно, некоторые из них, но доступные онлайновые документы были более чем достаточны для того, что я хотел сделать.

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

Перефразируя мой собственный блог post на эту тему, я думаю, что очень важно то, что Git не может пошатнуть свою репутацию из-за того, что с ним трудно работать. Цитата, с которой я столкнулся несколько раз, иллюстрирует это лучше, чем все, что приходит мне в голову: «Git изменился, чувак! Это не так, как раньше, теперь все интуитивно понятно! Вам просто нужно узнать, как он хранит данные! »

В заключение, я - пользователь Mercurial (я не использовал Git, но немного о нем читал), и мне редко нравится пользоваться программным продуктом, потому что в 95 +% случаев он сырой, с грубыми краями, ошибками и т. д. Mercurial - действительно решение, которое я люблю использовать и от всей души рекомендую!

5 голосов
/ 27 марта 2010

Я рекомендую hgbook (Mercurial: полное руководство) и hginit (Hg Init: руководство по Mercurial. Дружественное введение в Mercurial DVCS от Джоэла Спольски.)

См. Также мой ответ в Git and Mercurial - Сравните и сопоставьте ТАК вопрос.

4 голосов
/ 27 марта 2010

Если вы довольны git, я сомневаюсь, что есть реальная веская причина для перехода, хотя мне очень нравится Hg. У Git есть TortoiseGit / GitCheetah, хотя я думаю, что TortoiseHg немного лучше и стабильнее ИМХО.

Возможно, вы захотите посмотреть это бесплатное видео об использовании Hg и TortoiseHg (а также плагина Visual Studio Hg) на tekpub / codeplex . Видео даст вам ощущение ртути.

1 голос
/ 27 марта 2010

Я не могу говорить о Mercurial, но могу подтвердить, что git написан на C. Посмотрите на gitweb для источника.

Что касается необходимости командной строки для всего, что связано с git, вам не обязательно это нужно. Есть инструмент под названием TortoiseGit , который интегрируется с оболочкой проводника и будет управлять вашими git-репозиториями. Если вы используете Eclipse, есть также EGit . В Linux есть QGit, хотя CLI гораздо более мощный.

Я разработчик Linux / C и поэтому, естественно, предпочитаю Git; Я тоже слышал хорошие вещи о Mercurial, я просто никогда не удосужился узнать это.

0 голосов
/ 09 июня 2016

Я использую git и mercurial попеременно уже около 3 лет. Я настоятельно рекомендую Mercurial, если вам нужна стабильная система контроля версий. У нас были серьезные проблемы со стабильностью при использовании git с Atlassian Stash. Поэтому мы перешли на mercurial и использовали SCM в качестве слоя авторизации.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...