Доступен (https://www.mercurial-scm.org/wiki/Release4.9) релиз распределённой системы управления версиями Mercurial 4.9 (https://www.mercurial-scm.org/wiki/Release4.9). Код Mercurial написан на языке Python (требующие высокой производительности части оформлены в виде модулей на Си или Rust) и распространяется под лицензией GPLv2+. Среди проектов, использующих Mercurial, можно выделить следующие: Mozilla (https://hg.mozilla.org/), OpenOffice.org, OpenSolaris, NetBeans (http://hg.netbeans.org/main), OpenJDK (http://hg.openjdk.java.net/), Nginx (http://hg.nginx.org/nginx.org), Xine (https://anonscm.debian.org/hg/xine-lib/xine-lib/) и W3C.
Основные изменения (https://www.mercurial-scm.org/wiki/WhatsNew#Mercurial_4.9_.2...):
- Устранена уязвимость, позволяющая через использование символических ссылок и субрепозиториев обойти код для проверки путей и при клонировании подконтрольного репозитория организовать запись файла за пределы корневого каталога с репозиторием. В качестве обходного пути защиты можно запретить использование субрепозиториев (в секции
"[subrepos]" следует добавить опцию "allowed = false");- В команде 'hg histedit' предложен новый консольный интерфейс редактирвоания на базе библиотеки curses (для включения в 'ui.interface' или 'ui.interface.histedit' следует указать 'curses');
- Для новых репозиториев включена по умолчанию стратегия сохранения delta-изменений 'sparse-revlog';
- Добавлена новая опция 'rewrite.update-timestamp=True'для обновления данных о времени коммита после редактирования истории;
- Добавлена новая опция 'ui.message-output=stderr' для упрощения разбора сообщений с состоянием из скриптов;- Реализован новый шаблон файловых путей rootglob, позволяющий задать маску относительно корня репозитория;
- Продолжена переработка алгоритмов на языке Rust для повышения производительности.
URL: https://www.mercurial-scm.org/wiki/Release4.9
Новость: https://www.opennet.ru/opennews/art.shtml?num=50162
Я сам чопорный нудный ретроград, но почему бы разработчикам меркуриала просто не перейти на гит?
Потому что тебя не спросили.
Потому что у меркуриала есть некоторый список преимуществ перед гитом: у него проще и логичнее ui(не путать с gui), с ним гораздо сложнее сломать репу, потому как нельзя менять историю(поэтому он лучше подходит когда в команде есть непрограммисты)
Ну да, выковыривание мастера из релиза или неудачный ребейз смутят даже опытного пользователя.Но с другой стороны, сложность гита это плата за его гибкость.
> с ним гораздо сложнее сломать репу, потому как нельзя менять историю
> Добавлена новая опция 'rewrite.update-timestamp=True' для обновления данных о времени коммита после редактирования истории;ага
ну да, аноним выше неправ — править историю можно
> нельзя менять историюещё как можно
У вас 7 ошибок в слове "ретроград" - правильно писать "клоун". Потому что Меркуриал - это современная DVCS. А git - всего лишь поделие одиночки для патченья и версионирования раздутого ядра. Есть принципиальная разница в применении!
> современная DVCS.А что такое современная DVCS? И что в гите не позволяет ему быть современной DVCS?
а не конформист ли ты часом?
> а не конформист ли ты часом?Тот еще. DVCS - если я правильно понял, означает распределённую скв. Распределённость гита просто зашкаливает. Репозитории можно держать как в соседних папках, так и в разных доменах. всю историю можно восстановить если хотя бы кто-то по случайности не удалил репу со своей машины. Чего вам еще надо?
ну не знаю, звучишь как конформист, стадный инстинкт. Вот Mercurial для не таких как все, для нонконформистов. Не для фанатиков
>почему бы разработчикам меркуриала просто не перейти на гит?почему бы пользователям юникс не перейти на Винду? А почему бы пользователям андроид не перейти на айос? Вопрос из этой же категории, ну почти
>>почему бы разработчикам меркуриала просто не перейти на гит?
> почему бы пользователям юникс не перейти на Винду?Всем трем с половиной?
Тем более, пингвин всегда был не сильно "unix-like" (GNU is not unix), причем последние десять лет все меньше и меньше "like",
ведь "I don't think BSD is really too relevant anymore" и "I recommend developers to try to hack with only Linux in mind and experience the freedom and the opportunities this offers you" (с) The Red-Headed One and Only Lennart
> А почему бы пользователям андроид не перейти на айос?потому что айос это не для использования людьми, а для показа на презентации, разумеется.
>А почему бы пользователям андроид не перейти на айос?Кстати, давно пора бы. Т.н. "свободы" там примерно столько же, ну дык хотя бы не шпионит каждый первый индус.
да, у нас строгий отбор, нанимаем примерно одного из 10000 соискателей из моей деревушки под Бангалором. Больше нам и не надо, собственно - и так очередь желающих.
> Я сам чопорный нудный ретроград, но почему бы разработчикам меркуриала просто не перейти на гит?Вообще-то, ретроград вы наш, он появился раньше git. Так почему бы гиту не перейти на ртуть?
> он появился раньше gitА создатель сабжа считает иначе: "Mercurial is even younger (Linus had a few days' head start, ..." (http://lkml.iu.edu/hypermail/linux/kernel/0504.3/1404.html).
у гита один большой недостаток, после оглашения которого все остальные достоинства не имеют значения
Надо отдать должное — меркуриал тупо надёжнее гита. Недостатков ровно два: он на питоне и за ним не стоит армады IT-гигантов.
В каком месте он тупо надёжнее? В каком месте гит ненадёжен?
>В каком месте он тупо надёжнее?в слове "тупо"
> В каком месте гит ненадёжен?в самом главном
Их больше: метаданные репозитория занимают больше места чем в git. Обновление больших репозиториев (например, mozilla) занимает больше времени чем в git.
Абсолютно согласен. Но нам и не нужны "столпы ИТ" (которые на деле оказываются неповоротливыми бегемотами), потому что Hg работает и без них. Меркуриал - он просто лучший! Не идеальный, но конкуренты у него хромают на обе ноги.
> конкуренты у него хромают на обе ноги.На какие ноги хромают? Вы че, издеваетесь тут все?
ну как жеодна нога — UI про версии файлов с исходниками, а не про кишки git. бонусом в mercurial пытаются UI улучшать; в git патчи про UX тупо игнорятся jchamano.
вторая — безопасное переписывание истории.
бонус — не является воплощением сверхценных идей торвольца «переименование записывать не будем, будем угадывать!» и «пользовательские данные могут быть мусором»
> переименование записывать не будем, будем угадыватьлогично так как все остальные правки тоже через "угадывание".
так что протеворечий ни каких нет.
а ты как хотел бы -- чтобы патч был бы через "угадывание", но при этом переименование было бы строго записано?
поскольку имена файлов несут семантическую нагрузку, я бы хотел, чтобы оно явно записывало, что куда переименовано/скопировано. благо это не ракетная наука — mercurial умеет, bzr умеет, svn умеет, bitkeeper а «флагман» не умеет и уметь будет примерно никогда. так ещё и фанбои на разные голоса поют «это не нужно».да даже в diff --git явно записано, что куда переименовалось :)
> да даже в diff --git явно записано, что куда переименовалось :)git не сохраняет результат от diff.
Git - хромой от рождения, зарождался как "личный инструмент Трольвадса". Это и есть главный фэйл всех его поделий - полное отсутствие "большой, серьёзной концепции" - что ядро, что git.
Строгие ветки, невозможность смёржить более двух бранчей за раз и откат через исправляющий коммит - это круто, но мало. Всё это нивелируется питоном, притом старым.
Реальная история: у нас в конторе решили перейти с SVN на более современные системы и выбрали гит. С ним были траблы, потому как разные версии почему-то плохо дружили и доходило до потери и порчи данных. Ускоренно перебежали на ртуть и с ним таких проблем не было, но потом меркуриал коллапсировал из-за того, что один парень (фанат гита, кстати) влил файлы, где латинская "C" была заменена на кириллическую "С" и меркуриал (а это было пять лет назад) тупо выпадал в осадок с непонятной ошибкой. Причину и саботёра нашли и устранили довольно нескоро, а проект пришлось вести в SVN. В итоге начальство заявило, что если кому последний не нравится, то переходить будут только на TFS - а это та ещё шляпа.
Вы перепробовали много вариантов и всё равно у вас ничего не получается. Tfs точно вам поможет
там были большие проблемы с не-латинским юникодом (авторы с ним, очевидно, не встречаются), но, в отличие от вас, нашелся человек которому было надо, и который не поленился сообщить о проблеме разработчикам (заметьте, сам даже не особо в нее вникая - ну падает оно где-то там, воспроизводимо, сдаем баг в апстрим). Они еще пару дней позадавали уточняющие вопросы, и запилили фикс.если баги в апстрим не сдавать, и пытаться решать все проблемы всего используемого софта, даже с вменяемыми разработчиками, своими силами - то, конечно же, вас непременно спасет tfs. Сообщите как начнете переход, я попкорна побольше запасу.
P.S. жаль что его разработчики, кажется, окончательно собрались добить собственный бэкэнд в пользу гита. Но вы еще успеете и на эти грабли встать, торопитесь!
Угу. Поди выкачай через hg сырцы openjdk. Сколько раз пробовал (на разных версиях) - всегда падает (довольно долго качает, прогресс виден, но когда остаётся процентов 10-30 - падает). А выкачать git'ом какое-нибудь зеркало - всегда получается. Вполне вероятно, что-то надо донастроить. Но вот у гита настраивать не надо.
В отличие от гита в меркуриале можно выкачивать репозитарий порциями
> Угу. Поди выкачай через hg сырцы openjdk.это ничего, что этим ребятам почему-то захотелось приключений, сабрепы их чем-то не устроили и они написали наколенную поделку tclone, и именно она у них (скорее всего даже не у тебя, а их серверная сторона) как раз и падает?
Но виноват, конечно, меркуриал а не эти ребята у которых руки только под жаб заточены...впрочем, под йюх они у них на самом деле заточены. А меркуриал да, виноват - нехрен было писать на питоне, каждая жабамакака думает, что она легко и просто наляпает свой ни на что непохожий экстеншн. И наляпывает ведь - легко и просто, только вот - падаит, ууупс... а для гита написать сумела только microsoft (у нее и не падает)
а без жабьей отрыжки вот, пожалуйста:
srv2 /tmp> hg clone http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/
destination directory: jdk
requesting all changes
adding changesets
adding manifests
adding file changes
added 13428 changesets with 100503 changes to 27823 files
new changesets 37a05a11f281:f0b93fbd8cf8
updating to branch default
(тфьублин оно ж щас....)
23326 files updated, 0 files merged, 0 files removed, 0 files unresolvedну долго, шо ппц, но ведро линукса тоже не в секунду приезжает.
пойду удалять нахрен, забыл в суматохе -U
NetBeans после передачи его в апач мигрировал на git. Можно его уже в список укпроектов на mercurial не указывать.
У меня с меркуриалом были проблемы, когда сделал репу на флешке и хотел коммитить на разных компах. То ли разные версии были, то ли ещё что, но второй комп упорно не признавал репы первого. Так вроде меркуриал неплохо в плане юи, не надо задумываться с теми же bare repos, как в гит
> второй комп упорно не признавал репы первогоЭто и есть надежность меркуриала. Запомни, сынок: меркуриал надежен, а гит нет.
С гитом подобной проблемы у меня не было, почему-то
> Это и есть надежность меркуриала. Запомни, сынок: меркуриал надежен, а гит нет.+1
"..., а то так и будешь всю жизнь ключи подавать."
Забавная ситуация.
Я вот с дремучих времен работал с svn и даже делал мерджи в почти ручном режиме (по комментам). Знаю его плюсы и минусы. Где-то в 2008 познакомился и с hg и с git. Последний при общей прикольности идеи не очень понравился отсутствием истории переименований, не удобностью вести flow с персистентными ветками (ака develop master), а также непонятным выбором умолчательного поведения во многих командах. Он больше походил на БД хранения чего угодно, и мол если в вашем коде тоже бывает что угодно, то и для вашего кода тоже.Понятно дело ни hg, ни git в те времена никто и не хотел использовать. А если и использовали, то почти как svn с гигантскими комитами и почти без мерджей.
Я использовал hgsubversion с mq и мог делать всё как мне надо, даже если другие делали иначе. Изредка что-то делал и в гите.Время шло, Линус выступает в Гугле, появляются разные *hub'ы и вдруг git - это круто и молодежно. Везде PR'ы и MR'ы.
Недавно контора в которой я сейчас работаю решила перейти с svn на git - ну ок, все за, а мне почти без разницы.
Перешел с hgsubversion на hg-git с хранением intree=1, могу выбирать как работать через команды hg или git, проблем никаких.
А вот любители гита не могут сделать ни ребейз по человечески ни сквошить свои комиты и похоже даже не очень понимают что такое ветка в гите. Мол я раньше работал в крупной известной конторе и там в гите всё работало не парясь, а тут запускаю те же команды и возникают траблы - явно у вас гит не той системы.Пока меня это мало затрагивает, в те проекты я редко комичу.
И что-то мне подсказывает, что вопрос далеко не в том, что кто-то предпочитает hg, а не git...
Если гитом никто по-настоящему не умеет пользоваться, кроме Линуса - может, что-то в консерватории подправить?
> Если гитом никто по-настоящему не умеет пользоватьсяВнезапно, для некоторых открытие, что git - это не только pull/commit/push и иногда merge. И таких некоторых, кто пользует git как "модный svn с ветками", отчего-то много. Шаг в сторону, хоть git, хоть hg - хана, мы такого не проходили.
В hg вхождение несколько проще, разве что, а так, принципиально для освоения, разницы не особо.
Чтобы что-то осваивать, надо иметь в этом необходимость. С другой стороны, многие фанбои гита SVN толком не знают.
> Чтобы что-то осваивать, надо иметь в этом необходимостьНу так я и не призываю спрыгивать только потому, что это модно. Ест-но инструмент нужно брать исходя из потребностей. Если устраивает SVN, то почему бы и нет, если в целом устраивает.
> Чтобы что-то осваивать, надо иметь в этом необходимость. С другой стороны, многие
> фанбои гита SVN толком не знают.Ну, да. Именно!
"SVN толком не знают", ведь "чтобы что-то осваивать, надо иметь в этом необходимость."
Надеюсь вы то с гитом помучались.
смотрел как Линус свой гит нахваливал, как вообще он пришёл к идее написать свою CVS. Лично его интересовали такие фичи как лёгкость создавать и мержить ветки. В таких проектах как ядро линукс это наверное и годно, но в корпоративных условиях это наверное и не самое главное. Поэтому гит - потому что популярен.
его интересовала единственная фича - ничего не менять. "шлите патчи в рассылку, непременно нарезав мелкими ломтиками и каждый заверните в салфеточку".
поэтому и был написан уродливый набор врапперов, автоматизирующий ему именно такой уродливый workflow.а автор hg в это время просто взял и написал себе на коленке бесплатную (платная уже была) dvcs, решающую некоторые нерешаемые в svn/cvs проблемы.
>Линус свой гит нахваливал, как вообще он пришёл к идее
> написать свою CVS. Лично его интересовали такие фичи как лёгкость создавать
> и мержитьЕго интересовало _срисовать_ биткипер после того, как
МакВой зажал его би-и-исплатную __лицензию__.https://lwn.net/Articles/130746/
https://lwn.net/Articles/12120/
http://lwn.net/1999/features/BitKeeper.php3
https://lwn.net/Articles/574079/
https://www.opennet.ru/opennews/art.shtml?num=38016
https://en.wikipedia.org/wiki/Git#History
> Его интересовало _срисовать_ биткипер после того, какнет, ты опоздал родиться.
Его вообще не интересовал никакой биткипер - шлите патчи почтой, ой, я не прочитал ваше письмо, ваши труды пропали даром - ничего, пришлете еще раз, не рассыпетесь.
Тут много букв, я ниасилил, нарежьте по три строчки и перезаверните каждую.При этом несколько полунезависимых команд вполне себе пользовались cvs, но после окончательной фиксации изменений - вынуждены были почти вручную разбирать их на "нарежьте по три строчки" и вручную же засылать Господину.
Оно бы так и продолжалось по сей день, если бы у Биткипера не было очень ушлого продавца, по совместительству что-то там в свободное время ковырявшего в ядре.
Совершенно нечеловеческими усилиями трехлетней ездой по ушам (хороший, с-ка был менеджер!) тому удалось убедить Линуса, что можно хотя бы попробовать, и что там есть возможности, которые вполне подходят под его причудливый workflow, и чтоб ничего не менять - а поскольку он, собственно, и был владельцем компании, биткипер был запилен именно под эти задачи.
И даже всякие гейты в cvs и svn понаписали для тех самых команд, которые на неведомую да еще и с закрытым кодом полукоммерческую херню переходить вовсе не жаждали (прада, через пару лет, когда уже было никому не надо).Но в конечном итоге жадность чувака победила разум, ему начали везде мерещиться проклятые конкуренты, ворующие его прекрасные идеи при помощи отладчика (хотя на деле люди пытались хоть как-то наладить взаимодействие своих проектом с закрытой поделкой без интерфейса для плагинов)
и он начал не линукс кодить, а бороться за свой копирайт, угрожать судами, и т д - в результате закономерно был послан и было запилено такое же точно но под гепеле - автору линукса, как мы понимаем, было не впервой, и даже гражданин укушенный не рискнул ничего возражать.Разумеется, при запиливании было проигнорировано вообще все, что не укладывалось в линусовую концепцию использования, даже если оно в оригинале и было.
Ну а судьба биткипера была после этого вполне предсказуема - полтора кастомера, всеобщая ненависть и захоронение в могильник апача никому уже ненужного проекта.
Все бы и ничего, только из-за этого hg потерял одного из ключевых разработчиков и автора единственной вменяемой документации.
>> Его интересовало _срисовать_ биткипер после того, как
> нет, ты опоздал родиться.:-D
> Оно бы так и продолжалось по сей день, если бы у Биткипера
> не было очень ушлого продавца, по совместительству что-то там в свободное
> время ковырявшего в ядре.
> Совершенно нечеловеческими усилиями трехлетней ездой по ушам (хороший, с-ка был менеджер!)Ваше восхищение "талантливым продавцом" я вижу.
Ему, восхищению, вполне верю. Записываю: " по слухан на опенете, бездарного-ленивого-грубого пассана линуса научил vcs-ам талантливый продаван проприертари ". Ничего не перепутпал? Нуилан.
> Все бы и ничего, только из-за этого hg потерял одного из ключевых
> разработчиков и автора единственной вменяемой документации.А Hg -то при чём? //С нетерпением жду следующ ^W очередного TLDR-а. Спасибо! С удовольствием пропускаю всё, кроме первых и последних 3ёх строчек.
> Ничего не перепутпал?в общем, нет - то есть пытались многие (потому что в 98м году работать с большим проектом вообще без vcs уже только Линусу и приходило в голову), но, поскольку неправильно приседали и недостаточно низко кланялись, получилось только у продавана.
> А Hg -то при чём?
а там разработчик имел несчастье работать в коммерческой конторе, которая тоже использовала БК. Ну и получил ультиматум от того самого продавана. Видимо, зарплата была ему дороже хобби, и он поклялся на долларовой бумажке, что пока работает в этом месте, никакого отношения к hg иметь не будет.
Чувака зовут (звали?) Bryan O'Sullivan, он еще и автор hgbook, никакой современной адекватной замены которой, увы, нет ровно по этой же причине.
> Время шло, Линус выступает в Гугле, появляются разные *hub'ы и вдруг git - это круто и молодежно. Везде PR'ы и MR'ы.И, что характерно, ядро Linux разрабатывается не на Github. ;-) Увы, но Github не позволяет удобно вести большие проекты, распиленные на разные репозитарии.
> А вот любители гита не могут сделать ни ребейз по человечески ни сквошить свои комиты
Большинству людей из git достаточно знать clone/checkout/commit/push изредка fetch, ещё реже rebase. Зачастую даже ветки менять необязательно - достаточно master. И при всём этом убожестве получится принципиально лучше, чем без VCS.
В том то и дело, эти "clone/checkout/commit/push" в том или ином виде позволяет делать практически любая современная VCS с поправкой на конкретный flow принятый в проекте.
Знание только как нажать одну из этих кнопочек в типовом сценарии совсем не позволяет выдвигать хоть какое-то компетентное мнение о выборе VCS.
Большинство даже не очень понимают о каком flow речь, мол "как в github делать реквесты" и всё.
Иной раз даже имея возможность выбрать и VCS и flow под проект приходится учитывать этот масс-гитхаб эффект. Для некоторых это максимум во что они в принципе вникли бы и то только из-за массовости и ореола "крутизны". По факту умеют только самое базовое, а все иные кейсы разбирают и решают другие люди, которые в свою очередь редко бывают столь категоричны в мнении.
В lklm автору меркуриал довольно популярно объясняли в 2005м году ещё, почему меркуриал говно с его подходом к ведению истории и просадки производительности.
Потому что не git?
собаки лают, караван идёт
Так не лайте - охрипнете же.
Если не будут лаять, караван идти не будет, очевидно же!
Он давно упал в овраги
> Так не лайте - охрипнете же.classic kindergarten reversal
> В качестве обходного пути защиты можно запретить использование субрепозиториевзапретить субропозитории?!
а что мелочиться -- давайте сразу и репозитории запретим!
Мм, какая погремушка, что там со слиянием крест-накрест, после него так же рвёт башню? А версионированный .hgtags это зачем, кому конфликтов после косого criss-cross не хватило, может ещё вручную .hgtags помержить?
ну так может вам руки выпрямлять и не пытаться сливать несливаемое?> А версионированный .hgtags это зачем
это затем что мы хотим историю его изменений и да, возможность мержа с чужими.
А если вам теги не нужны или вам их босс назначает - ну так не лазте в этот файл, не будет проблем.
Они до сих пор на втором Python?