Представлен (http://gregoryszorc.com/blog/2015/05/04/mercurial-3.4-released/) релиз распределённой системы управления версиями Mercurial 3.4. Код Mercurial написан на языке Python (требующие высокой производительности части оформлены в виде модулей на Си) и распространяется под лицензией GPLv2+. Среди проектов, использующих Mercurial, можно выделить Mozilla, Python, OpenSolaris, NetBeans, OpenJDK, ALSA, Nginx, Xine, Dovecot, NTFS-3G и W3C.
Основные (https://groups.google.com/forum/#!msg/mozilla.dev.version-co...) новшества (http://mercurial.selenic.com/wiki/WhatsNew#Mercurial_3.4_.28...):
- По умолчанию на серверах задействован новый протокол bundle2, которому присвоен статус стабильного (в клиентах пока требуется явное включение bundle2). По сравнению с классическим протоколом, в bundle2 сокращено число этапов согласования соединения, что положительно сказалось на скорости выполнением операций push и pull, и дало возможность сделать данные операции атомарными. Кроме того, в протоколе предоставлены средства для обмена дополнительными метаданными в рамках установленного канала связи, что открывает широкие возможности для развития новшеств, например, уже продемонстрирована возможности автоматического перестроения (rebase) сервера при выполнении операции push. На сервере hg.mozilla.org поддержка нового протокола появится не раньше 1 июня.- Переписан код кэширования тегов, что позволило избавиться от узких мест с производительностью, проявляющихся при работе с очень большими репозиториями (например, для некоторых типов запросов к mozilla-central могли возникать подвисания в несколько секунд);
- В web-интерфейс hgweb добавлена возможность вывода в формате JSON для почти всех вызовов API. Поддержка JSON позволяет создавать новые настройки и сервисы, работающие с Mercurial.
- Компания Google подготовила новый бэкенд для хранения манифестов (списков файлов в коммите), который позволяет реализовать такие возможности, как клонирование только выбранных директорий. Новое хранилище позволит перенести репозитории l10n в mozilla-central;
- Связанные с вычислениями стадии переписаны на языке Си, что заметно отразилось на производительности;
- Приблизительно на 20% увеличена скорость работы команды "hg diff".
- Разработчиками из компании Google проведены оптимизации частей, используемых для чтения манифеста. Операции, подобные "hg export tip", стали выполняться в mozilla-central на 50% быстрее;- На файловых системах, не чувствительных к регистру символов в именах файлах, возросла производительность "hg status". На платформе OS X скорость работы "hg status" возросла на 25%. Производительность вызова "hg revert" в некоторых сценариях возросла до 4 раз;
- Добавлена команда "hg diff --root", позволяющая оценить различия, относительно произвольной директории;
- Добавлена команда "censor", которая позволяет цензурировать данные из прошлых коммитов. Например, если по ошибке в составе коммита в репозиторий переданы сведения, которые не подлежат разглашению, то команда "censor" позволяет закрыть эти данные от клонирования клиентами.- В основной состав перенесена функциональность расширения "hg record". Добавлен экспериментальный интерактивный консольный интерфейс, созданный при помощи библиотеки curses (включается через "experimental.crecord = true" );
- При вводе неизвестной команды, Mercurial теперь пытается исправить ошибку и предлагает наиболее близкую рабочую команду;- Устранены появившиеся в прошлом выпуске регрессивные изменения, проявляющиеся проблемами с производительностью при обращении к hg.mozilla.org через web-интерфейс;
- Для дополнений предоставлены средства для создания собственных обработчиков для редактирования истории операций (histedit)
- Mercurial 3.4 объявлен последним выпуском, в котором поддерживаются ветки Python 2.4 и 2.5.
Достоинства Mercurial:- Быстродействие:
- Высокая производительность работы с хранилищем, не зависящая от числа элементом в нём (O(1) revlog);- Компактное хранение данных в проиндексированном и сжатом виде;
- Оптимизирован для эффективной работы с данными на жёстком диске;
- Все изменения и файлы в репозитории дополнительно проиндексированы;
- Для копирования данных по сети используется HTTP и SSH, данные передаются в сжатом виде.
- Масштабирование
- Распределённая модель разработки позволяет участвовать в проекте неограниченному числу разработчиков;- Допускается произвольное слияние отдельных децентрализованных репозиториев, поддерживаемых отдельными разработчиками;
- Объём репозитория, число файлов и зафиксированных изменений не отражается отрицательно на производительности;
- При работе нет необходимости ждать освобождения блокировки.
- Надёжность.
- Для контроля целостности данных в репозитории используется SHA1;
- Хранилище реализовано в журнальном виде - данные не замещаются, а добавляются. Ведётся журнал транзакций;
- Быстрый алгоритм проверки целостности репозитория;
- Встроенные средства резервного копирования и проверки целостности;
- Удобство использования.
- Привычный CVS-подобный набор команд;
- Наличие встроенной системы подсказки;
- Интегрированный Web-интерфейс;
- Большой выбор GUI интерфейсов (http://www.selenic.com/mercurial/wiki/index.cgi/GUIClients).
- Лёгкость внедрения:
- Поддержка платформ UNIX, OS X и Windows;- Средства (http://www.selenic.com/mercurial/wiki/index.cgi/RepositoryCo...), упрощающие миграцию с других систем управления исходными текстами;
- Поддержка нескольких моделей организации репозитория: централизованная cvs-подобная, децентрализованная иерархическая и распределённая полуиерархическая;
- Поддержка внешних обработчиков и дополнений.
URL: http://gregoryszorc.com/blog/2015/05/04/mercurial-3.4-released/
Новость: http://www.opennet.me/opennews/art.shtml?num=42165
Мне кажется hg.mozilla.org и без регрессий всегда тормозил. Но это торможение меркнет на фоне скорости поиска в багтрекере :-)
А шо вы таки хотели, когда там багзилла и поиск по ПОДСТРОКЕ ))))
Ну так до них только начинает доползать:
> Связанные с вычислениями стадии переписаны на языке СиЕсли б они не выделывались со своим бидончиком - их участь была менее печальна. А так все-равно половину на си пришлось переписать, потому что Питон Не Тормозит!!!111
Только до этого они получили бодрый заряд антипиара "hg - тормозилово".
> Привычный CVS-подобный набор команд;интересно, почему это является достоинством в 2015 году?
Давайте переведу.
Несомненным плюсом Mercurial над Git является, то что у него не git-образный набор команд))
Так-то команды отражают внутренние понятия. Я думаю, если бы в git вписывался в локальной работе в режим CVS/SVN, то там тоже использовали бы такие же команды. Хотя кто знает этого Торвальдса)
Несомненным плюсом Mercurial над Git является наличие приватного репозитория в bitbucket, а так и забыли бы все про него...
У меня три десятка приватных git репозитариев в bitbucket.
> Несомненным плюсом Mercurial над Git является наличие приватного репозитория в bitbucket,А что, юные жлоборасы, фапающие на hg - даже свой сервер не способны нынче поставить?
Если что, существует ещё и gitlab: https://gitlab.com/
Там можно и юзать приватные репозитории на их центральном сервере, и вообще установить на своём серве. У меня на одной из работ применяли (свой серв).
> Несомненным плюсом Mercurial над Git является, то что у него не git-образный
> набор команд))Не вижу в чем тут достоинство. Мимикрия под древнее гoвно в DVCS? Это как если бы пульт электровоза пытался мимикрировать под привычные всяким ретардам вожжи.
Git в роли первой VCS - это как Emacs/Vim в роли первого редактора или C++/Haskell в роли первого языка.
> это как Emacs/VimКак вы смеете упоминать эту поделку наравне с божественным Emacs-ом?
В ОС Emacs уже появился нормальный редактор?
Сто лет же как vim прикрутили ! :-p
> нормальный редактор?М-x butterfly
Ну или для начинающих
M-x list-packages
и выбираете по вкусу.
Из всего этого разве что Haskell не может быть первым.На git собственно ручно сажал некоторое количество народу именно как на первую VCS. Как раз теми, кто не испорчен CVS/SVN он довольно легко осваивается. Это жертвы SVN с парой add/commit освоиться не могут и с тем, что репозиторий - это единое целое, а не пачка независимых каталогов.
vim/emacs - плевать, в для какого редактора распечатать cheatsheet с двумя десятками основных команд.
Плюсы - hello world в них пишется совершенно так же, как в каком нибудь паскале или бейсике. Все объектные фишки (и даже идея о выделении памяти) начинающему абсолютно не можны, их добавлять потом.
По последним данным, vim переезжает на github и соответственно git
Mercurial - лучший! Дай бог, чтобы его и дальше продвигали. А нечаянный революционер пусть дальше пилит свой "версионник ядра" ОТДЕЛЬНО от мэйнстрима.
Для этого "лучшего" надо вагон всякой питонятины тащить.
Git тянет с собой Perl и Tcl/Tk.
Наверно в какой-нить убунте. У меня в source-based системе этого не тянется.
В git есть и python, и perl, и shell, и Tk. Будут ли работать соответствующие компоненты --- зависит от наличия, само собой.
Это Совершенно Другое Дело
> Это Совершенно Другое ДелоЕстественно. Core то там писали нормальные спецы, на языках которые для этого лучше подходят. Бидонисты из hg это тоже начинают осознавать. Но, как говорится, too lillte and too late.
то-то я смотрю это ваше core так легко из другого ЯП позвать, что его переписали на всём чем можно (C#, Java, Python и даже «более лучше подходящем» C (libgit2)).
> то-то я смотрю это ваше core так легко из другого ЯП позвать,Его просто позвать в "unix way" - из консольных тулзов.
> что его переписали на всём чем можно (C#, Java, Python и
> даже «более лучше подходящем» C (libgit2)).А это вообще не было частью плана и сделано совсем другими людьми. А что, бидонятина откуда-то так уж легко зовется, кроме бидона? Ну раз уж мы об этом...
> Его просто позвать в "unix way" - из консольных тулзов.и собссно на этом кейсе уровня «выложить домашку на гитхаб» простота заканчивается.
>> что его переписали на всём чем можно (C#, Java, Python и
>> даже «более лучше подходящем» C (libgit2)).
> А это вообще не было частью плана и сделано совсем другими людьми.А был ли маль^Wплан вообще? В пользу отсутствия оного говорят ad-hoc интерфейс, небрежная документация, отсутствие альтернатив CLI. В пользу присутствия говорила бы гиперссылка на помянутый план, да вот не попадалась как-то.
> А что, бидонятина откуда-то так уж легко зовется, кроме бидона? Ну раз уж мы об этом...
не то чтобы легко, но вот конкретно у hg для такого есть http://mercurial.selenic.com/wiki/CommandServer
> и собссно на этом кейсе уровня «выложить домашку на гитхаб» простота заканчивается.Ну как бы в разработке софта есть такая штука: приоритеты. Вот Торвальдс умеет их разумно расставлять, за что его все и любят.
Для DVCS какой первый приоритет? Наверное, хорошо рулить версиями софта в распределенном виде и быть помощником разработчика. Ну и не греть мозг искусственными ограничениями на ровном месте и тормозами. С этим git справляется на ура.
Всякие апи-шмапи, для всяких вебанашек и микрософтов желающих такое же, но в MSVS - это ХРЕНАДЦАТЫЙ приоритет. Вон матерые зубры от ядра линукса "домашку" выкладывают. И это - покруче любого что ты вывалишь через апи (или как там еще). И вообще, как видим, если штука хорошая - они там сами себе апи сделают.
А питонисты сделали все наоборот. Получилась галимая DVCS, тормозная, мимикрирующая под доисторический шит, "зато с апи" и "зато на питончике". Но большинству художников не очень хочется превращаться в карандашную фабрику для того чтобы смочь порисовать. Поэтому усиленно махать перед их носом аргументом "зато теперь делать себе карандаши на кухне из подручных материалов может даже идиoт!" достаточно спорное начинание. Ну то-есть, чем-то плохим это не является, но вопрос то в приортетах. А вот тут то мы и видим что всякая скриптошваль vs матерый системный зубр - "моська vs слон" на айтишный манер.
>> А это вообще не было частью плана и сделано совсем другими людьми.
> А был ли маль^Wплан вообще?Некий - был. Core алгоритмики с самого начала было надизайнено с задействованием головы, с рядом полезных свойств. Чтобы быть компактным и быстрым. Человеком который это реально может сделать, таковых на этой планете немного.
А то что всякие апи опытный PM засунул туда где им самое место, в хренадцатые приоритеты - так это как раз правильно. Перец сделал хорошую DVCS. Все остальное - приложилось. Само. Just as planned. А эта куча assclown что сделали? Кусок непотребства. Зато с апи и на бидончике. А когда до них дошло что на фоне гита такая дрянь никому не сдалась ни с апи, ни на питоне - они конечно начали переписывать куски core на си. Но теперь они узнают что такоe "too little and too late" на примере своего проекта. Проект станет месивом где надо знать 2 напрочь разных ЯП. Проблемы производительности - чинятся только сильно опосля. А апи к гиту тем временем уже давно запилили те, кому это было надо. А хорошее core алгоритмики с хорошим примером как его реализовывать - уже было сразу. В отличие от этого бидономесива.
> В пользу отсутствия оного говорят ad-hoc интерфейс,
Что значит - ad-hoc? Командлайновый интерфейс там достаточно продуманный. Настолько, что я в половине случаев догадываюсь что там надо набрать, даже не читав ман. Я просто подозреваю что вот эта фича по уму должна быть сделана вот так. Что характерно - так чаще всего и оказывается.
> небрежная документация, отсутствие альтернатив CLI.
Ну так оно делалось для разработчиков предпочитающих работу а-ля разработчики Linux, т.е. с использованием автоматизации в *никс-образном стиле. Чего для разработчиков выше крыши. Это обеспечило симпатии профессионалов, со всеми вытекающими. А всякие гомнохостинги которым апи надо - свои проблемы решили сами, как видим. У них специфичные нужды и поэтому странно перетягивать ресурсы разработчиков на низкоприоритетную фичу. Если так делать - получится сpaнь типа hg, с гнилым core, которое приходится истошно костылировать, зато кучей финтифлюшек.
> В пользу присутствия говорила бы гиперссылка
> на помянутый план, да вот не попадалась как-то.Я уж не помню где я нашел, но Торвальдс рассказывал как он эту штуку делал. Вкратце: что может сделать системщик, разрабатывающий ядро? Ну, нечто типа версионированной FS. Для хранения сорцов что-то такое и надо. Там же Торвальдс рассказал и про выбор алгоритмов и прочая. План был логичен - сделать свою DVCS. Лучше чем у других. Это у него получилось. А всякие там апи-шмапи изначально просто не часть понятия VCS и являются достаточно опциональной хренью.
> не то чтобы легко,
Что особенно иронично в свете всяких libgit2, которые, конечно не заслуга Торвальдса, но ... но в том то и профессионализм PM, чтобы приоритеты правильно расставить и работы правильно распределить. Когда качественная работа core продемонтсрирована - тут уже толпа народа может подорваться апи писать. А когда это шыт типа hg - ему никакое апи не поможет. Гули толку от апи при х-вом core? А, ну скрипткиды не могут в приоритеты и иерархии - они ж нубье.
> но вот конкретно у hg для такого есть
> http://mercurial.selenic.com/wiki/CommandServerЭто у бидонистов теперь называется кульным апи? :) Знаешь, для легкой автоматизации по месту, средствами програмера, которому желательно на заточку карандашей минимум времени потратить и пойти художествовать - будет проще git куда-нибудь запайпить средствами шелла. А для тяжеловесных кастомных заморочек как видим народ сам себе напилил libgit2 и что им там еще было надо. А hg получился некоей фигней "ни два ни полтора". Прямо по Черномырдину.
> А питонисты сделали все наоборот.Всё бы хорошо, но есть одна проблема — разработку Mercurial начал (и продолжает) Matt Mackall, разработчик ядра Linux. Не очень подходит под профиль твоего мифического «питониста», м? Но ты продолжай натягивать сову на глобус, practice makes perfect.
История из BitKeeper, как я понимаю, благополучно утерялась, поэтому поиском находятся только копирайты там-сям https://github.com/torvalds/linux/search?utf8=%E2%... из 1999-2005.
Tcl/Tk только для GUI.
Но ребейзить в нем по-человечески всё еще нельзя.
Ребейз - это костыль для неосиливших нелинейную историю, он не может быть по-человечески.
> Ребейз - это костыль для неосиливших нелинейную историю, он не может быть
> по-человечески.Ну хорошо, уговорил! Многосторонний мерж то они осилили? А то нелинейная история у всех и вся - это круто, но как-то синхронизировать усилия в конечном итоге все-таки придется! :)
> Но ребейзить в нем по-человечески всё еще нельзя.define "по-человечески"
Давным-давно осилили: http://mercurial.selenic.com/wiki/RebaseExtensionЧто именно не по человечески?
1) Из статуса паблик нужно переводить в драфт, иначе не ребейзится.
2) После пуша в апстрим-репе ДВЕ ОДНОИМЕННЫХ ВЕТКИ, та что до ребейза и которая после ребейза. И нахрена мне старая ветка?
> Добавлена команда "censor", которая позволяет цензурировать данные из прошлых коммитов. Например, если по ошибке в составе коммита в репозиторий переданы сведения, которые не подлежат разглашению, то команда "censor" позволяет закрыть эти данные от клонирования клиентами.Смахивает на эпичный костыль.
главное — ни в коем случае не пытаться разобраться, так ли это на самом деле
> главное — ни в коем случае не пытаться разобраться, так ли это
> на самом делеГлавное - понять нафуя это в dvcs. Какой-то костыль для переклиненых на централизованной модели.
особенно если кто-то успел скачать
Вот странно, да.
Если никто не успел скачать - так отреврайтить и всё.
А если кто-то успел, то уже поздняк метаться.
> Смахивает на эпичный костыль.как всё остальное в hg, это норм.
И это хорошо.
в ртути архитектурный косяк, который никто не собирается фиксить - имя ветки входит в коммит. Поэтому буээ, неприятно пользоваться.
всем известно, что если за софтом не следить, он не будет развиваться. Плагин с гитоветками лежит в коробке с 2009, с февраля 2012 он стало core feature, но кому какое дело? Ведь фатальные недостатки Mercurial — название (не матчится с /^git$/) и отсутствие Торвольца в кредитсах, а потому любой уважающий себя хипстор от программирования в его сторону даже голову не повернёт.
это как раз его достоинство :-)