LINUX.ORG.RU

Mercurial 3.8

 


0

7

Вышла очередная версия Mercurial — распределённой системы управления версиями, написанной на Python.

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

fsmonitor

Добавлено расширение fsmonitor (ранее известное как «hgwatchman»), разработанное компанией Facebook. Такие операции, как hg status, hg diff, hg commit должны знать о том, какие файлы в репозитории были изменены. В нормальной ситуации это требует обращения к каждому файлу для проверки изменений. fsmonitor использует сервис watchman, чтобы получать уведомления об изменениях. watchman в свою очередь, использует специфичные для платформы API, такие как inotify или FSevents, чтобы получать уведомления от операционной системы всякий раз, когда файл в хранилище изменился. Используя fsmonitor, команды hg status, hg diff и другие, должны проверять только те файлы, которые на самом деле изменились, вместо того, чтобы обходить всё хранилище.

automv

Другим важным изменением является введение экспериментального расширения automv. Обычно, люди перемещают файлы в своих репозиториях используя команды hg mv или hg cp. Несмотря на это, вполне легко забыть об этих командах и использовать обычное перемещение, особенно при использовании IDE. Расширение automv пытается определить похожие файлы при коммите и отмечает их как перемещённые/скопированные.

chg

Новый интегрированный chg клиент предоставляет альтернативный способ запуска Mercurial команд. Причиной низкой производительности Mercurial с точки зрения скорости команд является то, что он написан на Python. Это обычно не ограничивающий фактор, но запуск интерпретатора добавляет некоторые накладные расходы. Chg решает эту проблему, используя клиент, реализованный на C, и сервер на Python. Вместо того, чтобы запускать интерпретатор Python для каждой команды, вызов chg запускает простое C-приложение, которое общается с сервером команд.

>>> Примечания к выпуску

>>> Подробности

★★★★★

Проверено: leave ()
Последнее исправление: Psych218 (всего исправлений: 3)

У Git совершенно инопланетянский интерфейс (CLI — тоже интерфейс), hg в разы проще для освоения, поэтому я выбрал именно ртуть. Если в случае с git я даже запушить в удалённый репозиторий не смог с первого раза, не говоря уже о сложных вещах типа бранчей, то в hg всё просто и понятно.

the_electric_hand ★★
()

запуск интерпретатора добавляет некоторые накладные расходы. Chg решает эту проблему, используя клиент, реализованный на C и сервер на Python

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

P.S. Напоминаю на всякий случай, что hg > svn >> git.

CARS ★★★★
()
Ответ на: комментарий от CARS

рассово

Ну ты и тролль. «Расово» пишется с одной «с»! В остальном, вроде, все верно написал.

Virtuos86 ★★★★★
()

кроме «гит сложна, ниасилил, наркоманский» какие-то фактические функциональные преимущества есть?

Debasher ★★★★★
()
Ответ на: комментарий от CARS

>

hg > svn >> git.

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

Camel ★★★★★
()

Расширение automv пытается определить похожие файлы при коммите и отмечает их как перемещённые/скопированные

Шел 2016-й год.

anonymous
()
Ответ на: комментарий от anonymous

Расширение automv пытается определить похожие файлы при коммите и отмечает их как перемещённые/скопированные

Шел 2016-й год.

Наконец-то для тех, кто не осилил addremove, сделали расширение.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

А если есть - ты перейдешь? %)

ну может и да, не на работе конечно, вдруг будет какой-нибудь сильный аргумент чтобы свои домашние хелоуворлды на него перевести)

Debasher ★★★★★
()
Ответ на: комментарий от Debasher

какие-то фактические функциональные преимущества есть?

Рабочий TortoiseHG под всё, например, а не только под масдай.

d_a ★★★★★
()
Ответ на: комментарий от Debasher

кроме «гит сложна, ниасилил, наркоманский» какие-то фактические функциональные преимущества есть?

[я уже приводил эту ссылку в прошлых тредах] При ОЧЕНЬ БОЛЬШОЙ кодовой базе, git захлебывается: https://medium.com/@prasoon2211/mercurial-vs-git-scaling-and-architecture-94f...

X-Pilot ★★★★★
()
Ответ на: комментарий от Debasher

Например, нет необходимости делать git gc. Но недостатков больше - нельзя простым способом удалить локальную / удалённую ветку, нельзя сделать наподобие git clone --depth=1 ...

qwerty93
()
Ответ на: комментарий от qwerty93

нельзя простым способом удалить локальную / удалённую ветку

Локальную - можно, hg strip. Удаленную нельзя, и это прекрасно.

tailgunner ★★★★★
()
Ответ на: комментарий от Debasher

может это кому-то и клёво, но мне нужен CLI)

В корпоративной среде клёво, да, так как там в техпроцессе масса товарищей различной степени прошаренности. Но вопрос-то был не про твои личные хотелки, а про существующие преимущества. Или нет?

d_a ★★★★★
()
Ответ на: комментарий от kto_tama

каков самый известный большой проект, разработанный ма меркурие ?

Facebook, наверное.

tailgunner ★★★★★
()
Ответ на: комментарий от qwerty93

hg strip нужно подключать как расширение?

Да.

В hg можно скачать только актуальную кодовую базу, т.е. ~ git clone --depth=1 ... ?

Без .hg? Наверное, через hg serve. Но зачем? Использование VCS как механизма деплоя - злокачественное хипстерство.

tailgunner ★★★★★
()
Ответ на: комментарий от littlechris

tailgunner> Наконец-то для тех, кто не осилил addremove, сделали расширение.

littlechris> это для инвали^W любителей угадывать, что в куда скопировалось/переименовалось

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

anonymous
()
Ответ на: комментарий от anonymous

У одного надо обязательно руками делать addremove, у другого очевидно и addremove придуман для инвалидов.

Не стану спрашивать, из чего именно это тебе очевидно.

Ничего, привыкните, что у вас тоже оно есть

Оно у нас есть уже несколько лет.

tailgunner ★★★★★
()

Chg решает эту проблему, используя клиент, реализованный на C и сервер на Python.

пропущена запятая после «реализованный на C».

Novel ★★★★
()
Ответ на: комментарий от X-Pilot

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

... we took a long, hard look at improving it to work at scale. After much deliberation, we concluded that Git's internals would be difficult to work with for an ambitious scaling project.

When we first started working on Mercurial, we found that it was slower than Git in several notable areas.

To narrow this performance gap, we've contributed over 500 patches to Mercurial over the last year and a half. These range from new graph algorithms to rewrites of tight loops in native code.

причем все это время гит тоже на месте не стоял, а эта информация уже серьезно устарела

waker ★★★★★
()
Последнее исправление: waker (всего исправлений: 1)

Фанаты сабжа все поголовно наркоманы. Помню пару лет назад читал блог одного такого, тот плакал, что в меркуриале сделали по умолчанию букмарки вместо именованных веток. Единственный аргумент против нововведения был озвучен как «это ж получится что мы проиграли гиту».

anonymous
()
Ответ на: комментарий от qwerty93

нельзя простым способом удалить локальную / удалённую ветку

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

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

waker ★★★★★
()
Ответ на: комментарий от anonymous

в меркуриале сделали по умолчанию букмарки вместо именованных веток

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

это ж получится что мы проиграли гиту

ты даже не представляешь, насколько это больная тема у разработчиков хг :D

думаю, подсознательно они и сами это понимают. но вслух никогда не признают.

waker ★★★★★
()
Последнее исправление: waker (всего исправлений: 1)

Линус Торвальдс просил передать всем ЛОРовцам, что он не одобряет mercurial.

anonymous
()
Ответ на: комментарий от tailgunner

Но зачем? Использование VCS как механизма деплоя - злокачественное хипстерство.

Экономия трафика/времени? Если проект слишком большой, не всем нужна полностью вся история.

EXL ★★★★★
()

По описанию какое-то переписывание git на питоне получается.

Radjah ★★★★★
()
Ответ на: комментарий от waker

В git считается нормой создавать ветки на каждый чих. Обнаружена ошибка -> заводится новая ветка -> ведётся работа по исправлению в новой ветке -> результат мержится в основную ветвь. После чего bugfix-ветку можно смело удалять. Вопрос: в hg эта информация считается слишком важной, чтобы не удалять или в hg в принципе другой подход и ветка --- вещь более тяжеловесная и долгоживущая?

ugoday ★★★★★
()
Ответ на: комментарий от ugoday

В hg несколько видов веток. И просто безымянная ветка создается автоматически при коммите.

tailgunner ★★★★★
()
Ответ на: FSBook от Camel

у гугла больше кодовая база но я не вкурсе или они закончили миграцию

val-amart ★★★★★
()
Ответ на: комментарий от CARS

P.S. Напоминаю на всякий случай, что hg > svn >> git.
«> ... >>»

эх, еле распарсил, что это трамплинчики из старых добрых компьютерных игр

anonymous
()
Ответ на: комментарий от waker

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

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

Фишка hg в его изначально плагиной архитектуре. Там вообще нет проблем с тем, чтобы встроить что нибудь на любой этап обработки дерева коммитов. Что собственно и сделали в фейсбуке.

А по факту получилось коммчно - hg созданный для разработчиков, чтобы они могли легко его расширять, оказался невостребованным. Зато дубовый git, который никак под себя не подстроишь пользуется популярностью благодаря авторитету Линуса.

anonymous
()
Ответ на: комментарий от Debasher

А у тебя его кто-то отобрал? Что интересного в TortoiseHG --- это наличие консоли прямо в ГУИ. Я пока еще ни в одном другом клиенте этого не видел.

anonymous
()
Ответ на: комментарий от tailgunner

а, ну да. багрепорта этого не видел но учитывая формат хранения это не удивительно.

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

хотя да, это фундаментальная проблема формата хранения. посмотрим, что pyd с бандл2 сделает с этим.

val-amart ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.