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

Ответ 1

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

Инженер тоже здесь. Я использовал Mercurial, Subversion, BitKeeper и CVS. Пока не дошли до Git.

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

Не уверен, что здесь подразумевалось, Git и Mercurial - это инструменты командной строки в глубине души.

Как он обрабатывает репозитории?

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

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

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

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

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

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

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

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

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

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

Похоже на мои вещи. Не считая необработанных данных, конечно.

И вне темы...

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

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

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

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

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

Ответ 2

Git Плюсы:

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

Git Минусы:

• Крутая кривая обучения
• Инструменты GUI существуют, но (IMO) не все это твердое

HG Плюсы:

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

HG Минусы:

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

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

Ответ 3

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

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

Ответ 4

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

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

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

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

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

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

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

Ответ 5

Я возьму его по частям...

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

Mercurial имел преимущество в Windows, но я считаю, что Git улучшился там, поэтому он, вероятно, не является хорошим отличием.

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

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

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

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

Чтобы перефразировать мой собственный блог сообщение по этому вопросу, я думаю, что это очень важно, так это то, что Git can not, похоже, потрясет его репутацию за трудность работы. Цитата, которую я натолкнула на несколько раз, иллюстрирует это лучше, чем все, что приходит мне на ум: "Git s changed, man! Это не так, как раньше, это совершенно интуитивно! Теперь вы просто узнаете, как он хранит данные!"

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

Ответ 6

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

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

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

• HgSccPackage требует Mercurial
• VisualHG требует TortoiseHg

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

• Bitbucket - бесплатный план имеет 1 частный репо и 1 ГБ дискового пространства.
• CodePlex - Использование Mercurial в CodePlex

Для руководств и руководств вы можете начать с Mercurial wiki.

Ответ 7

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

См. также мой ответ в Git и Mercurial - сравнение и контраст Вопрос SO.

Ответ 8

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

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

Ответ 9

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

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

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

Ответ 10

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