мерзавец против меркуриальной производительности

Question

Существуют ли какие-либо критерии производительности?

Я хочу создать репо и зафиксировать / подтолкнуть к унаследованному коду, который работает на нескольких гигабайтах.

Является ли быстрее / след и т. Д.?

Прошу прощения, если это слишком расплывчато ...

Answer 1

Вы не выбираете между git и mercurial из-за производительности.Они оба хороши.

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

По пространству, Git однозначно выиграет, если у вас будет одинаковый контент на множестве разных путей в его жизни.То есть, если ваши несколько концертов файлов будут перемещены.Модель git поддерживает это лучше, чем модель hg.Это очень хорошо, возможно, не имеет значения для вас.

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

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

Answer 2

Недавнее (январь 2011 г.) сравнение производительности между Mercurial и Git-сервером .Вывод таков: Mercurial дает более стабильную производительность, чем Git, но Git в среднем быстрее.

Answer 3

Оригинальный ответ (март 2011 г., на GitHub было менее 3 лет)

Правильная производительность для измерения DVCS (которая в любом случае выполняет все операции локально) - это одна из ваших повседневных задач:

• слияние (как быстро вы выбираете между различными моделями ветвления , особенно в Mercurial?)
• рабочий процесс публикации (как быстро вы настраиваете один push / pull worlflow ?)
• интеграция (как быстро вы интегрируете Git с IDE, например, с веб-приложением)Хадсон или Джира, или Redmine, или Track, или ...?)
• setup (как быстро вы настраиваете централизованное хранилище с каким механизмом аутентификации: это важно, если вы используете DVCS в корпоративной среде )

Необработанная базовая производительность не так уж важна, если вы понимаете ограничения для DVCS : вы не можетеесть один репо, в который вы бы пut все (все проекты или все виды файлов, например, двоичные файлы).
Необходимо провести некоторую реорганизацию модулей, чтобы определить правильное количество репо на «модули» (согласованные наборы файлов).

---

Обновление 2018, семь лет спустя: поддержка Git в Windows стала реальностью и направлена ​​на улучшение производительности и масштабируемости Git.

Чтобы проиллюстрировать это, у Microsoft есть вся База кода Windows в одном (гигантском) Git-репозитории: см. « Крупнейшее Git-репо на планете »: 3,5 млн. файлов, 300 ГБ, 4000 инженеров, выпускающих 1760 в день »«Лабораторные сборки» в 440 филиалах в дополнение к тысячам сборок для проверки запросов по запросу.
Но это с добавлением GVFS (Git Virtual FileSystem) , который позволяет динамически загружатьтолько те части, которые вам нужны, в зависимости от того, что вы используете.
Это , а не , но в Git native, хотя его интеграция началась в декабре прошлого года, с помощьюУзкое / частичное клонирование .

Answer 4

Как указал @MartinGeisler в своем ответе, время фиксации очень мало (если вы фиксируете через командную строку, оболочка немедленно возвращается).

Что занимает довольно много времени, так это сеть clone с / push эс / pull с. Google опубликовано небольшой тест (см. Сноску 1) , когда им пришлось выбирать DVCS для Google-код , но он довольно старый (лето 2008 года).

Answer 5

Эрик Синк опубликовал результаты эталона для SVN, Bazar, Mercurial, Git и его собственной Veracity.

К сожалению, это всего лишь одна операция (фиксация) с единой базой кода (Valgrind), и я не уверен, какую версию он использовал для всех этих VCS, но в любом случае она должна быть довольно старой, так как статья датируется до 2011 года. Наверное, поэтому сам Эрик определяет их как «Смешные ненаучные критерии». Во всяком случае, для чего это стоит:

SVN намного медленнее других (почти 22 секунды), но все остальные похожи (от 3 до 5 секунд). Git явно самый быстрый, и в процентном отношении он даже на намного быстрее, чем Mercurial (который занимает на 43% больше времени), но на самом деле мы говорим о разнице в 1,4 секунды - едва заметно.

Помимо этого, я не могу сейчас найти источники, но я несколько раз читал, что Git работает быстрее, хотя разница тривиальна (что подтверждает этот тест, проведенный Эриком). Так что я не стал бы сильно беспокоиться о скорости, выбирая, с кем идти.