Mercurial против Subversion. Чья производительность лучше? - PullRequest
2 голосов
/ 17 мая 2010

Есть много статей о SVN против Hg в целом. Я хотел бы сосредоточиться только на производительности.

Реальный опыт предпочтителен.

Вот моя установка:

(будущая настройка) Windows с IIS для Hg

(текущая настройка) SVN 1.3.2 поверх apache под windows

Я хотел бы иметь статистику для большинства операций с общими ресурсами (коммиты, статистика, локальные / удаленные извлечения, нажатия и т. Д.). Я не совсем уверен, каковы наиболее распространенные операции для ртути.

Производительность - не единственная вещь, которая имеет для нас значение, но она очень важна и может стать решающим моментом при переходе на Hg.

Однако я бы хотел посмотреть статистику. Как лог занял клон репо 5 гб? или что-то в этом роде.

Ответы [ 4 ]

7 голосов
/ 17 мая 2010

Во-первых, может быть, обновить вашу Subversion?

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

Допустим, Subversion превосходит Mercurial во всех отношениях. Большой! Если способ, которым вы и ваши коллеги используете ваш репозиторий, будет лучше подходить для Mercurial, вы станете с точки зрения производительности и глупой производительности.

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

2 голосов
/ 17 мая 2010

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

Итак, сначала вам нужно обновить SVN. Это легко, и как только вы запустите 'svnadmin pack' в своем репо, вы сможете правильно сравнить. 1.3.2 древнее! (текущая версия 1.6.11)

Во-вторых, вам нужно решить, важно ли для вас запускать и извлекать большие репозитории. Например, у меня есть репо 12 Гиг для управления. К счастью, svn позволяет нам получать только часть этого, а не все, поэтому управление им значительно улучшено.

Кроме того, в v1.7 появилось значительное улучшение производительности (готово, так скоро), так как производительность не была приоритетом для парней из SVN, они действительно добавили новые функции и обеспечили стабильную стабильность. В настоящее время производительность является проблемой и решается. Взгляните на список рассылки dev, чтобы увидеть. Возможно, стоит подождать немного (или оценить его с помощью копии вашего репо).

Видите ли, производительность вашей системы может быть одинаковой. Это может быть узким местом на IO, где svn обычно терпит неудачу (хотя в списке рассылки dev есть некоторые цифры из главы с сервером-монстром с raid-0 SSD, 24 ГБ ОЗУ и, как ни странно, это узкое место на ЦП!)

Итак, в общем, вы должны выяснить свой рабочий процесс и процессы. Если Mercurial (что является хорошим выбором) обеспечивает это для вас, тогда отлично, сделайте это. Но если это не так, то миграция не поможет вам, независимо от того, насколько быстрее это будет.

0 голосов
/ 18 мая 2010

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

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

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

0 голосов
/ 17 мая 2010

(Не совсем ответ, но все же он может предоставить полезный контекст для вашего вопроса:)

Как упоминалось в DVCS tools , самая распространенная операция в VCS, особеннораспределенный, это: слияние .

И что, независимо от вашей настройки, всегда будет проще и быстрее сделать с Mercurial, чем SVN.См .:

...