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

пользуется популярностью благодаря авторитету Линуса

Спорное утверждение.

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

прелесть меркуриала в том что есть масса способов как это решить

Как например?

remotefilelog

Это вообще другая вещь. Как говорится, можно замести грязь под коврик, но чище от этого не станет.

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

Как например?

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

Это вообще другая вещь

что поделаешь, но проблему решает.

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

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

Я так понимаю, что все решения включают в себя модификации кода Mercurial? Мы такие не рассматриваем.

либо удаленный ревлог или его часть

Ну, если под «удаленным ревлогом» понимать ссылки между ревлогами - да.

это реально такая большая проблема для вас?

Это реально проблема для нас, да. Жаль, что это не проблема для вас.

проблему решает.

При этом решении Mercurial практически перестает быть DVCS. Такая цена неприемлема (опять же, для нас).

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

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

очень самонадеянно. расскажешь об этом Андрею Александреску, или может Дженсу Аксбо, или Крису Мейсону, ммм?

просто инженеры в фейсбуке ниасилили пилить гит

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

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

ничем она не устарела, или пруф в студию, репозитория на (ой, нда). ну короче *большого* репозитория с большим рейтом изменений =)

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

или Крису Мейсону

Если это Мейсон, который пилил ReiserFS, я думаю, он тайный меркуриальщик %) Автор не меньше, чем mq.

ну короче *большого* репозитория с большим рейтом изменений =)

Кстати, когда-то ходили слухи о том, что Google и Facebook пишут систему управления версиями очень больших проектов, отдаленно основанную на Mercurial (вроде бы называлась она Piper). Ты не в курсе об том, как с ней обстоят дела?

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

Я так понимаю, что все решения включают в себя модификации кода Mercurial? Мы такие не рассматриваем.

да, увы. не хочешь попробовать пофиксить? pyd, sidd и Durham очень отзывчивые типы, и ты питон отлично знаешь.

При этом решении Mercurial практически перестает быть DVCS. Такая цена неприемлема (опять же, для нас).

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

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

Ровно противоположный опыт. С Git разобрался не читая мануал. С Hg не разобрался даже после двух месяцев разработки с его использованием. Применил силу и за час перевёл весь проект на Git.

anonymous
()

Не одобрено

Есть git. Все остальное от противного.

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

не хочешь попробовать пофиксить?

Я не потяну. Мэтт когда-то сказал very hard, так что это не работа на неделю-две.

конечно, центральный авторитативный источник при таком подходе должен быть

Вот именно. А мне нужно работать не в родной сети или без сети вообще.

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

Пробовал как-то перевести ~60Gb репозиторий Git на Hg чисто замерить скорость. В процессе импорта интерпретатор съедал всю доступную ему память и падал. Так и я и не узнал, насколько Hg быстрее и лучше скалируется, чем Git. А жаль.

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

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

В моём рабочем процессе в принципе нормально и ожидается создание отдельных веток под разные нужды, эксперименты и прочее. Для резервирования и обмена я часто публикую эти ветки в удалённом репозитории. Со временем их накапливаются совершенно неприличные сотни. Вопрос: как зачистить удалённо то, что потеряло смысл уже через 10 минут своего существования?

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

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

Пофиксил

anonymous
()

Кто-нибудь знает живые ppa или другие источники готовых сборок для Ubuntu?
А то «официальные» ppa давно загнулись, в основном репозитории говно мамонта, а самому собирать пока лень.

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

механизма деплоя

Экономия трафика

В 2016 уже можно не пользоваться модемными линками на 56k.

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

Если это Мейсон, который пилил ReiserFS, я думаю, он тайный меркуриальщик %) Автор не меньше, чем mq.

ого, не знал. он автор и мейнтейнер btrfs, не знал, что он еще и автор mq!

Ты не в курсе об том, как с ней обстоят дела?

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

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

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

Про git - чистая правда, такое гуано снесли бы в первый же день, если б не знали, что писал «сам»! А вот hg... даже не знаю, с чего б ему быть «невостребованным» - я поставил и юзаю. Мне есть какое-то дело, сколько красноглазиков сидят в git? Ничуть. Hg удобен, решает мои задачи, не заставляет «изучать тонкости», не парит мозг, не теряет файлы. По-моему, это и есть «история успеха»!

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

Какие есть аналоги GitLab для mercurial?

Хоспыдя, ребус для дошкольников! s/Git/Hg/ -> HgLab: https://hglabhq.com/ - Mercurial сервер для оффтопа. Писан на C#, так что есть все шансы перенести его «как родного» в Линукс. Но он платный. Зато не слеплен из г-на и палок тремя энтузиастами в выходные, т.е. ЭТО будет развиваться без форков и «переписываний с нуля».

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

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

Слеплен четырьмя?

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

вопрос такой: а тебе нужны именно бранчи? потому что скорее всего тебя нужны букмарки, и уже есть ремоут букмарки.

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

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

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

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

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

вопрос такой: а тебе нужны именно бранчи? потому что скорее всего тебя нужны букмарки, и уже есть ремоут букмарки.

Я не могу ответить на этот вопрос, так как не владею терминологией Hg в достаточной мере и не знаю разницы между «букмарками» и бранчами. Если это важно, количество изменений в бранче может быть значительным, вплоть до переписывания большинства файлов полностью.

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

Вот именно. А мне нужно работать не в родной сети или без сети вообще.

ну ты можешь работать, коннект нужен только если ты попробуешь что-то сделать с коммитами которые не скешированны локально. то же что и при sparse checkout. а цель именно уменьшить размер чекаута репы чтобы сэкономить дисковое пространство?

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

Как создать «scratch-репозиторий» в Mercurial? Залезть на сервер и создать? А как потом оповестить неизвестное количество заинтересованных лиц о его существовании? А как сделать аналог «git branch -A | grep tmp/» с таким подходом?

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

Как создать «scratch-репозиторий» в Mercurial? Залезть на сервер и создать?

Да. А в чем проблема? Options -> Fork в Kallithea.

А как потом оповестить неизвестное количество заинтересованных лиц о его существовании?

Почта? Жаббер? Скайп? Pull-request? Просто создание репозитория под тем же именем, если общение слишком сложно?

А как сделать аналог «git branch -A | grep tmp/» с таким подходом?

Хм. Так у тебя бранчи удалены (т.е. из БД удалены объекты, им соответствующие) или висят в истории, невидимые?

tailgunner ★★★★★
()

git = github = community. Некуда деваться с подводной лодки, хочешь чтобы в проекте участвовал ещё кто-то, кроме тебя - используй гит.

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

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

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

А так почти всегда и бывает, тулза созданная для насущной задачи здесь и сейчас (Git как замена существующей комерческой тулзы для Linux сурс контрола которая неожиданно поменяла лицензию) выигрывает у попытки создать «идеальную куклу» (Hg) для всех (предположительно долго выдумывая архитектуру).

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

тулза созданная для насущной задачи здесь и сейчас (Git как замена существующей комерческой тулзы для Linux сурс контрола которая неожиданно поменяла лицензию) выигрывает

Конкретно Git выиграл именно за счет пиара - имя Линуса привлекло достаточно кодеров, чтобы допилить изначальное говно (первые год-два пользоваться им было почти невозможно).

предположительно долго выдумывая архитектуру

ЕМНИП, Mercurial вышел на 2 недели раньше Git.

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

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

Как я понимаю, log или ann прилично не вызовешь.

а цель именно уменьшить размер чекаута репы чтобы сэкономить дисковое пространство?

Уменьшить размеры именно репозитория, не чекаута.

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

Да. А в чем проблема? Options -> Fork в Kallithea.

Для этого нужно ставить и поддерживать в актуальном состоянии довольно сложное ПО. Это неоправданные накладные расходы для решения такой тривиальной проблемы. Есть ли аналог gitolite?

Почта? Жаббер? Скайп? Pull-request? Просто создание репозитория под тем же именем, если общение слишком сложно?

В текущем процессе заинтересованные стороны не всегда люди. Более того, имена бранчей — или как ты предлагаешь репозиториев — могут быть совершенно любыми и имеют только общий префикс «tmp/».

Хм. Так у тебя бранчи удалены (т.е. из БД удалены объекты, им соответствующие) или висят в истории, невидимые?

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

Я склоняюсь к мысли, что Mercurial, возможно, не подходит для нашего процесса. Это не делает его плохим, но вот поди ж ты!

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

У hg релиз по расписанию. Да, вот так, уныло и неинтересно.

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

Для этого нужно ставить и поддерживать в актуальном состоянии довольно сложное ПО

Это «довольно сложное ПО» облегчает процесс разработки.

Есть ли аналог gitolite?

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

В текущем процессе заинтересованные стороны не всегда люди

Для не-людей зачем вообще удалять мусор?

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

Если вы завязали свой процесс на уникальную возможность Git - естественно.

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

Какие есть аналоги GitLab для mercurial?

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

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

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

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

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

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

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

Если вы завязали свой процесс на уникальную возможность Git - естественно.

да нет в этом ничего уникального, технически историю-то менять можно, просто это глубокий антипаттерн. к тому же, он может просто букмарками сделать то же самое, а если ему головы лишние мешают, то пожалуйста без редактирования истории тоже можно их «закрыть» через `hg commit --close-branch`.

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

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

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

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

log работает, аннотации — нет. метаинформация на клиенте все-равно вся есть. но уменьшить размер репы это все не поможет, да.

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

фанатикам наплевать. hg

  • записывает copy/move *явно*
  • может попробовать угадать, что в куда переименовалось/скопировалось (hg help addremove и ключ -S), но всё равно *записывает* явно, что в куда скопировано/перемещено.

git записывает только снапшоты («есть вот такие файлы, внутри у них вот такое»), и ответ на вопрос «какой файл стал каким» получает сравнением хэшей содержимого. Или, если хэши не совпадают (что в разработке ПО чаще всего и бывает), угадыванием. Которое выполняется в момент вычисления разницы между коммитами.

а addremove лично я использую много-много реже, чем hg mv/cp, так что да, automv не особо нужно

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

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

а что если им на самом деле просто пофиг? philosoraptor.jpg

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

Или, если хэши не совпадают (что в разработке ПО чаще всего и бывает), угадыванием. Которое выполняется в момент вычисления разницы между коммитами.

На мелких файлах (допустим, тонны POJO, которые вдруг потребовалось изменить) оно плохо работает: git будет считать, что файлы удалялись/создавались, а это не так.

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