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)

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

чувак в принципе не одобрял подход только потому что это по-гитовому.

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

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

Как земля

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

anonymous
()

Интересно, Mercurial или что-то подобное на его идеях потянет распределённый документооборот объёмом около десяти терабайт редко и часто изменяемой полезной информации (тексты, блобы до 100 МБ)?

iZEN ★★★★★
()
Ответ на: Как земля от anonymous

Ветки-то в гите норм, но интерфейс...

кто к чему привык. у меня на интерфейс hg аналогичная реакция.

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

К тому времени, когда человек узнаёт про fetch, он уже обычно несколько месяцев уверенно пользуется Git. В случае с Mercurial вопросы и заплывы по тысячестраничному мануалу начинаются ещё при первом запуске.

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

Окей, поясню: не поддерживается pull-request merge. Для меня это было критично, поскольку я хотел следующей модели разработки: каждый разработчик работает в локальных бранчах, делает пуш на сервер. После чего уже на сервере делается merge в главную ветку. Таким образом, актуальная главная ветка всегда одна — на сервере, и ее всегда можно подгрузить себе. А когда главная ветка как у Пети, так и у Маши, начинается бардак. В итоге перешел на гит и гитлаб.

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

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

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

Осторожно, обнаружен голос здравомыслия в этом треде.

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

кто к чему привык. у меня на интерфейс hg аналогичная реакция.

ОК, приведи конкретные претензии к интерфейсу hg. Про гит уже сто раз обсосано.

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

Есть, конечно, Kallithea, но смысл от сервера, когда он не поддерживает pull request?

А что, kallithea не поддерживает pull request?

Окей, поясню: не поддерживается pull-request merge

Спасибо, родной, за доброту. Но в будущем попробуй выражаться общепринятыми терминами вроде «server-side merge».

Таким образом, актуальная главная ветка всегда одна — на сервере, и ее всегда можно подгрузить себе. А когда главная ветка как у Пети, так и у Маши, начинается бардак.

Бардак, как обычно, в голове.

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от X-Pilot

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

Статья ниочём, кстати. Обещает объяснить, почему меркуриал масштабируется лучше гита, в итоге кратко рассказывает историю создания обеих систем и пришествия фейсбука в меркуриал, ну и добавляет немного про кишки системы, которые уже 100 лет в обед как не соответствуют действительности. Ну и никаких замеров, просто говорится, что в гит команда статус на большой базе может занимать до 30 секунд, не уточняя сколько у меркуриала.

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

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

Бардак, как обычно, в голове.

Это называется «возможность выстрелить в ногу», от них нужно по возможности уходить.

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

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

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

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

Крис вон оказывается автор MQ extension, но это было задолго до фб. энивей, ты же не считаешь всерьез что кроме Александреску, тебя и авторов гита божественную сишечку никто ниасилил? все дело в коммьюнити.

val-amart ★★★★★
()

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

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

ОК, приведи конкретные претензии к интерфейсу hg. Про гит уже сто раз обсосано.

мне это не интересно.

edit: уже тоже сто раз обсосано

waker ★★★★★
()
Последнее исправление: waker (всего исправлений: 1)
Ответ на: комментарий от val-amart

Крис вон оказывается автор MQ extension, но это было задолго до фб. энивей, ты же не считаешь всерьез что кроме Александреску, тебя и авторов гита божественную сишечку никто ниасилил? все дело в коммьюнити.

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

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

я пользуюсь обоими системами ежедневно, и мне git во всем больше нравится

Это касается только организации рабочего процесса? А то что Git на Си (как и DeaDBeeF), а Mercurial на Python (и отсюда скорость Git и тормознутость Mercurial) повлияло на симпатию к Git?

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

можно было бы. 500 это кстати без модулей, там еще полторы тысячи. только мейнтейнеры гита сразу дали понять: такие изменения не примут.

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

в hg всё просто и понятно

3 простых вопроса:

1. Как исправить неправильный комментарий у ревизии (элементарная опечатка при коммите)?

2. Как получить список ВСЕХ репозиториев на удаленном сервере (и заодно - не вводить URL-адрес вручную в TortoiseHg при клонировании)? В браузер список выводится (если запустить hg serve), а вот в консоли/TortoiseHg - никак.

3. Как сделать автоматический update до последней ревизии на удаленном сервере при push?

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

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

Это касается только организации рабочего процесса?

не понял вопрос

А то что Git на Си (как и DeaDBeeF), а Mercurial на Python (и отсюда скорость Git и тормознутость Mercurial) повлияло на симпатию к Git?

да хоть на C#, какая разница? главное чтобы работало хорошо.

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

только мейнтейнеры гита сразу дали понять: такие изменения не примут.

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

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

Как сделать автоматический update до последней ревизии на удаленном сервере при push?

один из разрабов меркуриала говорил мне, что это в hg есть, и очень давно (раньше чем в гите). но, возможно, соврал - я не проверял.

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

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

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

1. Как исправить неправильный комментарий у ревизии (элементарная опечатка при коммите)?

histedit, опция m

2. Как получить список ВСЕХ репозиториев на удаленном сервере (и заодно - не вводить URL-адрес вручную в TortoiseHg при клонировании)? В браузер список выводится (если запустить hg serve), а вот в консоли/TortoiseHg - никак.

без понятия зачем это может быть нужно, но если можно забрать с браузера — можно забрать курлом %)

3. Как сделать автоматический update до последней ревизии на удаленном сервере при push?

changegroup hook

вывод: ниасилил

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

скрипт лол.

echo '[hooks]' >> .hg/hgrc
echo 'changegroup.myupdate = hg up' >> .hg/hgrc

две строчки в hgrc записать.

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

histedit, опция m

Как это делать через TortoiseHg (или другую GUI оболочку)? Этот histedit туда не интегрируется.

без понятия зачем это может быть нужно,

Аутистам разумеется не нужно, а вот нормальным программистам - нужно, чтобы при клонировании можно было просто выбрать репозиторий из списка (например, раскрывающегося комбо-бокса), а не набирать URL вручную.

но если можно забрать с браузера — можно забрать курлом %)

Можно и код на Java набирать в vim без автокомплита, и гланды удалять через задний проход - но удобно ли это?

changegroup hook

Про это я и сказал - «написать скрипт», хотя это необходимая базовая функциональность (как и предыдущие 2 пункта).

вывод: ниасилил

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

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

ясно все с тобой. «написать скрипт» это две строчки в конфиг прописать? в какой же магической системе контроля версий это делается проще для любых обезьян типа тебя?

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

понятие локальных веток означает не совсем то же самое, что в гите

О, а можешь подробнее разъяснить этот момент? С hg я знаком поверхностно (только как юзер), с гитом чуть получше (засылал им несколько патчей).

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

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

Ну тогда весь смысл статьи полностью теряется. Примерно как рассказ, типа сначала я торговал пирожками со стойки, потом купил ещё одну стойку и нанял продавца, а потом умер мой дядя и оставил мне миллиард в наследство. Кстати, гит тоже можно расширять. Есть куча параметров для работы на низком уровне, многие команды, по крайней мере раньше, были реализованы в виде скриптов. Так что, чисто теоретически, ничто не мешает повесить демона и реализовать команду git fstatus. Если для реализации потребуется пара «plumbing» команд, вряд ли будет проблемой их добавить. В конце концов, даже если будут упираться, никто не помешает сделать свою ветку с этими командами. Но в общем, я согласен с гитовцами: если для реализации фичи, которая может пригодиться 0.01% пользователей требуется интегрировать в SCM демона, то на фиг эту фичу.

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

Ну ты дебил, что уж поделать

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

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

Ничего не напоминает?

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

в mercurial у вас просто не получится (сходу, см. hg help phase, ключ --force) отредактировать коммиты, которые есть в опубликованном репозитории. что заметно экономит время.

littlechris ★★★
()

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

не в случае IDEA

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

Интересно, Mercurial или что-то подобное на его идеях потянет распределённый документооборот объёмом около десяти терабайт редко и часто изменяемой полезной информации (тексты, блобы до 100 МБ)?

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

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

mercurial когда-то давно использовал, синтаксис cli утилит гораздо менее укурен и вообще штука приятная, но git победил :(

Мальчик! Линус Торвальдс тобой доволен.

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

Про это я и сказал - «написать скрипт»

Ты точно программист? Я слышал от девочек-эйчарщиц, что HTML — это такой ЯП, но там хотя бы можно за что-то зацепиться. Но воспринимать ini-файл как скрипт... это прекрасно просто. Прекрасно!

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

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

Пока не прочитаешь все сраные 700 страниц талмуджа

С любой более-менее сложной вещью так. Точка. Интуитивно понятный интерфейс есть только один - это сиська.

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