Состоялся (http://mathiasdm.com/2016/05/03/mercurial-3-7-and-3-8/) релиз распределённой системы управления версиями Mercurial 3.8 (https://www.mercurial-scm.org/wiki/Release3.8). Код Mercurial написан на языке Python (требующие высокой производительности части оформлены в виде модулей на Си) и распространяется под лицензией GPLv2+. Среди проектов, использующих Mercurial, можно выделить следующие: Mozilla, Python, Go, OpenOffice.org, OpenSolaris, NetBeans, OpenJDK, ALSA, Nginx, Xine, Dovecot, NTFS-3G и W3C.
Основные изменения (https://www.mercurial-scm.org/wiki/WhatsNew):
- Устранена опасная уязвимость CVE-2016-3105, которая может привести к выполнению кода злоумышленника при выполнении конвертации Git-репозитория с использованием расширения convert;
- В состав включено разработанное компанией Facebook расширение fsmonitor (https://www.mercurial-scm.org/wiki/FsMonitorExtension), которое использует средства отслеживания изменений в ФС (inotify, FSevents и т.п.) для ускорения выполнения команд, подобных "hg status", "hg diff" и "hg commit". Ускорение достигается за счет обработки событий изменения от ФС вместо проверки перебором всех файлов;
- Добавлено экспериментальное расширение automv, которое автоматизирует определение фактов переименования и копирования файлов в репозитории без применения команд "hg mv" и "hg cp";- Добавлен клиент chg (https://www.mercurial-scm.org/wiki/CHg), предоставляющий альтернативный способ выполнения команд Mercurial и работающий значительно быстрее. В отличие от штатного интерфейса, целиком написанного на языке Python, chg разделён на клиентскую и серверную часть: клиент написан на Си, а сервер на Python.
URL: http://mathiasdm.com/2016/05/03/mercurial-3-7-and-3-8/
Новость: http://www.opennet.dev/opennews/art.shtml?num=44372
Всегда привлекала лаконичность команд hg, а работать приходится с git :(
Use https://hg-git.github.io/ Luke! Для 99% проектов оно годится. Естественно, конвертации largefiles ⇔ Git-LFS нет.
Сам-то пользовался?
> Сам-то пользовался?Да, рекомендую.
Release In Peace...
Для ознакомления с программизмом hg безусловно меньшее из зол (и прекрасно справится с текстами и подобными мелочами), а выбравшие программизм смогут легко сами прочитать про git.Есть аналогия: Pascal изначально заточен для ознакомления с вопросами типа "что такое цикл" и он с этим успешно справляется, а при выборе программистской работы один фэншуй изучать конкретные инструменты.
Есть только ма-аленькая проблема: поцкаль ломает мозг синдромом утёнка.И потом, когда йуный прогромизд приходит на собеседование, то ни на чём на реально используемом не может изобразить сортировку пузырьком. И от осознания этого факта он начинает рассказывать по форумам про "незаслуженно забытый идеальный поцкаль", и "оно удобно для обучения".
Время - конечный и очень дорогой ресурс.
А некоторые на собеседовании могут не понять как написанных код на собеседовании компилируется gcc и работает как нужно, хоть и выглядит как ...
> А некоторые на собеседовании могут не понять как написанных код на собеседовании
> компилируется gcc и работает как нужно, хоть и выглядит как ...А некоторые на собеседовании могут не понять как написанный код компилируется и работает как нужно, хоть и выглядит как ...
Какое отношение синдром утенка имеет к неумению программировать? Если в этом умозрительном собеседовании поменять Pascal и C местами, то что изменится?
> Есть только ма-аленькая проблема: поцкаль ломает мозг синдромом утёнка.Синдром утёнка - это вредная привычка, которая настолько часто встречается, что ей даже дали название. Язык тут не при чём.
Я ж вот спокойно прошёл путь от бейсика до лиспов, [и вроде ни с каким утёнком проблем не было / и всем не доволен] (нужное подчеркнуть). :)
О, теоретики пожаловали. Ты ведь не писал в команде ничего на продажу, правильно?Язык тут очень даже при чём. Поцкаль не даёт представления о том, с чем человек столкнётся при создании реальных программ, и я не вижу причин тратить на него время.
Например, после поцкаля приходится объяснять как работают указатели. Как работает конкатенация и сравнение строки, а также откуда там O(n). Почему обход массива может работать с разной скоростью в зависимости от направления обхода. Что такое стек, куча, и чем они отличаются. Что такое коллбаки и зачем они бывают нужны. А также многое-многое другое.
Берём простенький qsort(void *base, size_t nmemb, size_t size, int (*compar)(const void *, const void *)) и любитель поцкаля сразу начинает пучить глаза: нам такого не задавали, ШТОЭТА.
А ушибленных дельфями практически гарантированно нужно ПЕРЕучивать с нуля, ибо норовят нахepачить всю логику в обработчиках одного гигантского суперкласса "Appilcation".
> Например, после поцкаля приходится объяснять как работают указатели.
> Почему обход массива
> может работать с разной скоростью в зависимости от направления обхода. Что
> такое стек, куча, и чем они отличаются. Что такое коллбакиТеоретик, не видевший паскаля, пожаловал?
А народ, когда-то раньше ради лулзов писавший дрова на дельфя-паскалях, да и FPC шники в придачу:
http://wiki.lazarus.freepascal.org/linux/kernel/module_devel...
и незнали!
> О, теоретики пожаловали. Ты ведь не писал в команде ничего на продажу, правильно?Ну почти:
http://solarsecurity.ru/products/solar_dozor/
https://www.linkedin.com/in/dmitrii-kashin-47105611a> Язык тут очень даже при чём. Поцкаль не даёт представления о том,
> с чем человек столкнётся при создании реальных программ, и я не
> вижу причин тратить на него время.А когда новичок сталкивается с реальной разработкой в продакшене, он почти 100% оказывается не готов. Как минимум к тому, что 95% работы - это разгребание страшной хрени, которая писалась поколениями программистов, с обилием ужасных легаси, отсутствием современных примочек, которые молодняку казались уже само собой разумеющимся. Это нужны железные нервы.
Как дошел до того, что занимаешься созданием системы слежки за "нелояльными сотрудниками"? Смени хоть аватар, не примазывайся к GNU.
Это он грехи замаливает.
Ты упрямо пытаешься натянуть собственный успешный опыт на общее положение в индустрии. Открой вакансии, посчитай там поцкаль, с++ и c#.> А когда новичок сталкивается с реальной разработкой в продакшене, он почти 100% оказывается не готов.
ДОучивать приходится всех, а вот поцкалистов - приходится ПЕРЕУЧИВАТЬ. Чуешь разницу?
И "разгребание страшной хрени", почему то в большинстве своём написанной на с++/c# - отнюдь не дают бонусов поцкалистам.
> Ты упрямо пытаешься натянуть собственный успешный опыт на общее положение в индустрии.
> Открой вакансии, посчитай там поцкаль, с++ и c#.То, что в списке вакансий что-то превалирует, никак не свидетельствует о том, плох язык или хорош. Вот опять же, откройте список вакансий и посмотрите: плюсы и ява там требуются повсеместно, а вакансий на лисп и окмал - почти нет. Так что это не показатель.
> ДОучивать приходится всех, а вот поцкалистов - приходится ПЕРЕУЧИВАТЬ. Чуешь разницу?
Проблема не в паскале. Проблема в людях. Вон тот же php вроде не плохой язык, но сообщество у него - просто ужас.
К тому же, кто такие эти самые "поцкалисты"? Разрабочик нынче обязан быть полиглотом. Если разработчик знает только один язык, пусть даже популярный и востребованный, то ему ещё до полноценного разраба ползти и ползти.
> Так что это не показательЭто как раз-таки показатель для языка. Если какой-то язык решает конкретные актуальные практические задачи - его будут использовать, даже если он чудовищен по дизайну. За примерами далеко ходить не надо: php, js, 1C. Условно - java, go.
И наоборот, пока придумыватели идеально-сферической фигни допилят свою вундервафлю, и выкатят релиз - окажется, что а) ниша уже занята, б) инструменты/библиотеки под "ужасный" язык написаны, в) сообществом наработан богатый опыт по обходу граблей и неудачных моментов в языка, г) написана куча мануалов "как сделать X на Y для чайников".
И внезапно оказывается, что вундервафля уже и не особо нужна. И пользуются ей создатели, кучка гиков, которым не в лом выучить 15й язык, и xипстеры для кидания понтов.
Примеры вундервафель: как раз-таки Ocaml, Vala, Rust, D. Да, в чём-то они лучше, только где они были 20 лет назад?
> Проблема не в паскале. Проблема в людях.
Что за либеpальная незaмутнённость, опять народ не тот? Другого у меня для вас нет. ©
> Вон тот же php вроде не плохой язык, но сообщество у него - просто ужас.
Это пхп-то "не плохой язык"? "вроде", аа, значит не сталкивался. Вобщем, я так скажу - его сообщество - это очень точное отражение языка. Я ни знаю ни одного прогера, который бы серьёзно продвинулся как программист, после перехода на пхп. Это та самая "система для дeбилoв", щедро посыпанная граблями.
> К тому же, кто такие эти самые "поцкалисты"?
Это слегка неадекватные личности, типа той что ниже, которые предлагают драйвера писать на поцкале. :-)
> Разрабочик нынче обязан быть полиглотом. Если разработчик знает только один язык, пусть даже популярный и востребованный, то ему ещё до полноценного разраба ползти и ползти.
Разработчик никому ничего не *обязан*, это раз. Если он, к примеру, хороший фортранщик, сидит в каком-нибудь НИИ уже 20 лет, его текущие навыки востребованы, и других не требуется - почему бы и нет. Да, его ждёт сюрприз при попытке устроиться в другое место, но это его личное дело. Может он после НИИ на пенсию собирается или в садоводы переквалифицироваться.
Во-вторых, птицу видно по помёту, а мастера - по его набору инструментов. Как я уже говорил, время на обучение ограничено, а мозг не резиновый. Если типовой разработчик наберёт в багаж фигни - при попытке походить по собеседованиям будет или срочно переучиваться, или будет курить бамбук, если не сможет. Количество вакансий по языкам - см выше. Всё просто.
Вы ошибочно считаете, что причина неиспользования некоторых языков заключается в том, что они не решают актуальные практические задачи. Но это не так. Основная проблема вундервафель - это высокий порог вхождения.Этот порог служит в некотором роде фильтром специалистов. Преодолевшие этот порог программисты создают модули (библиотеки) очень хорошего качества.
Потому эти самые "вундервафли" не только очень даже приспособлены для решения актуальных практических задач, но и успешно делают это. Благодаря ним стартапы из 1-2х человек, бывает, успешно конкурируют с серьёзными корпоративными продуктами.
За примерами тоже, в общем-то, не нужно далеко ходить.
[1] http://www.paulgraham.com/avg.html
>Ты упрямо пытаешься натянуть собственный успешный опыт на общее положение в индустрии. Открой вакансии, посчитай там поцкаль, с++ и c#.и javascript
и кто потом из популярности выведет качество?
>>посчитай там поцкаль, с++ и c#.
> и javascript"— И животноводство! — Вскричал вдруг требовательно Петенька Скоробогатов,"...
>> О, теоретики пожаловали. Ты ведь не писал в команде ничего на продажу, правильно?Ну, положим я, работая в фирме, связанной с ж/д, писал вполне себе софт на продажу. И (о, ужас!) мало того, что этот софт сейчас работает повсеместно на РЖД, так он ещё и писан не просто на паскале (ужас!), а на (ужас-ужас!!!) дельфи! И что самое страшно, этот софт ещё и продолжает до сих пор развиваться!
>> Язык тут очень даже при чём. Поцкаль не даёт представления о том, с чем человек столкнётся при создании реальных программ, и я не вижу причин тратить на него время.
Вот этой фразой вы сразу дали понять, что к программированию вы ну совсем никаким местом не относитесь.
Честно говоря, дальше ваш… гм… даже и анализировать неохота.
О, дипломированный формошлёп пожаловал.> И (о, ужас!) мало того, что этот софт сейчас работает повсеместно на РЖД,
О качестве работы нашего РЖД (и вообще большинства ФГУП) уже давно ходят легенды, не в последнюю очередь из-за качества местных IT. И этот гадюшник давно пора прочистить напалмом.
> И что самое страшно, этот софт ещё и продолжает до сих пор развиваться!
А в половине банкоматов до сих пор икспишечка без секьюрити апдейтов. Мало того, в общепите до сих пор жива такая гадость как rkeeper4. А в коммуналке - lantab. Не показатель ни разу.
> даже и анализировать неохота.
Так чего вылез?
>> О, дипломированный формошлёп пожаловал.Хм… А кроме того, что в Дельфи удобно делать формы, Вы ещё что-то о ней знаете? И да, диплома по «формошлёпству» у меня нет, т.к. я занимался вещами, непосредственно пользователю невидимыми.
[ … бред о гадюшниках и старом софте … ]
Весь мир насилья мы разрушим, а затем?..
Почему бы, вот к примеру, Вам не взяться и не написать альтернативу на каком-нибудь модном C♯ (или по какому явыку у Вас диплом?) и не предложить сию альтернативу соответсвующим организациям?Ломать — не строить, а на форуме сидеть — не мешки ворочать.
> Весь мир насилья мы разрушим, а затем?..Скажем так, не от меня эта ситуация зависит. Если ваше IT-начальство допускает использование дельфи - Столлман им судья, однако пусть не обижаются, когда окажется, что:
а) их поделка намертво прибита к венде (не увидел ни одного упоминания лазаруса),
б) новых кадров для её поддержки на рынке не найти (bus factor = 1-2),
в) проблемы с поиском даже новых не-ключевых разработчиков (ФГУП? поддерживать кривулю на паскале? за 30тр? да за кого вы меня держите?),
г) проблемы с поддержкой/развитием как таковые (модули устаревают, уязвимости находят, поддерживать это тупо некому)...и всё это, как обычно, всплывает ВНЕЗАПНО, в контексте очередного импортозамещения.
> Почему бы, вот к примеру, Вам не взяться и не написать альтернативу
Предлагаешь мне бесплатно купировать ваши многолетние прoeбы и забивание на техдолг? Мальчик, тебе сколько лет?
>> а) их поделка намертво прибита к венде (не увидел ни одного упоминания лазаруса),Да, именно так. И даже более того, к определённым версиям Windows.
>> б) новых кадров для её поддержки на рынке не найти (bus factor = 1-2),
>> в) проблемы с поиском даже новых не-ключевых разработчиков (ФГУП? поддерживать кривулю на паскале? за 30тр? да за кого вы меня держите?),
>> г) проблемы с поддержкой/развитием как таковые (модули устаревают, уязвимости находят, поддерживать это тупо некому)Тем не менее, люди находятся и работают, и поддерживают, и развивают. И да, названная Вами сумма, вполне себе зарплата программиста в нашем регионе.
>> Предлагаешь мне бесплатно купировать ваши многолетние прoeбы и забивание на техдолг?
Разве кто-то говорил о «бесплатно»? Разговор шёл о комерческом продукте, продаваемом за вполне реальные деньги.
>> Мальчик, тебе сколько лет?
Прости, девочка, но для тебя я слишком стар.
>> Весь мир насилья мы разрушим, а затем?..
> Скажем так, не от меня эта ситуация зависит. Если ваше IT-начальство допускает
> использование дельфи - Столлман им судья, однако пусть не обижаются, когдачто, на PHP или Node.js это окажется лучше? По вашей логике разработчиков на этих платформах найти не проблема — на улице их как грязи. Так берём их за 15 тысяч рублей в месяц и не выеживаемся. Десяток не справится — новых наймём. :))
Изя в очередной раз выставил себя идиотом. :-)
> объяснять как работают указатели.
> Что такое стек, куча, и чем они отличаются.
> Что такое коллбакиУважаемый эксперт уверен, что этого нет в "поцкале"?
> Почему обход массива может работать с разной скоростью в зависимости от направления обхода.
А начинающий с сишки узнает о кэшах сразу, бонусом, получая еще и +100500 не только на ЧСВ, но и на все скиллы!
> Уважаемый эксперт уверен, что этого нет в "поцкале"?Я уверен, что в сишка окунает тебя в это сразу и гарантированно. Выжил - значит годен в программисты. В отличие от.
> А начинающий с сишки узнает о кэшах сразу, бонусом, получая еще и
> +100500 не только на ЧСВ, но и на все скиллы!А это уже нарабатывается в процессе, нечего передёргивать.
> Я уверен, что в сишка окунает тебя в это сразу и гарантированно.
> Выжил - значит годен в программисты. В отличие от.Сишка неплохо учится после паскаля. Паскалсты раньше саундбластер напрямую програмили, если что. Но это не дельфисты, которые кнопочки на формочку расставляют и сейчас они на сях и плюсах наворачивают за троих.
>Всегда привлекала лаконичность команд hg, а работать приходится с git :(
> Среди проектов, использующих Mercurial, можно выделить следующие: ... Python ...Список то редеет, теперь его нужно всё время обновлять, а не копипастить из новостей годовой давности.
И ALSA тоже давно не использует hg
Чорт, Dovecot и NTFS-3G тоже давно ушли на git. В самом деле пора каждый раз проверять список.
> В самом деле пора каждый раз проверять список.Какой список?
Будешь пользователем меркуриала?
Последним?
А чё, круто же звучит: "последний пользователь меркуриала". #нетакойкаквсе и прочая-прочая
Ещё понимаю переход hg->git, но обратный.. не разумею.
Лично я пробовал вкатиться на git, исплевался (тем более что дело происходило под Windows), попробовал hg и втянулся. Тут всё очень приятно, лаконично и продуманно. Как в питоне.Хочу спросить у тех, кто полноценно юзал как hg, так и git, чем последний функционально лучше?
Git просто более популярный и всё. Многие большие проекты переходят на git для того, чтобы другим пользователям/программистам которые коммитят было проще. Т.к. они знают только как работать с git.Я вот все публичные проекты тоже на git перевел и плююсь.
А домашние закрытые проекты лежат на mercurial.
В 80-90% случаев ничем. У git одно преимущество, у него есть есть распиаренный github (и ядро Linux), и потому он более популярен.
>> Хочу спросить у тех, кто полноценно юзал как hg, так и git, чем последний функционально лучше?Я полноценно использовал и SVN, и hg, и git.
Для работы в команде над закрытым проектом (своё оборудование, централизованная сборка и тестирование) выгоднее SVN. Не то, чтоб DVCS тут негодны, но они не дают никаких преимуществ. От слова «совсем».
hg логичен и бысто осваеваем. Подходит для большенства личных и разрабатываемых в команде проектов. Большой плюс: _полная_ история (к сожалению, под давлением фанатив git, это уже уходит в историю), порой незаменимая при разборе полётов.
git — тоже, что и hg. Минусы: 1) нелогичность и 2) прямо таки подталкивание в сторону убиения истории. Плюс: один из авторов Линус Товальдс (хотя кто-то сочтёт это минусом).
> Большой плюс: _полная_ история (к сожалению, под давлением фанатив git, это уже уходит в историю)А можно тут подробнее: имеются ввиду squash commits?
>> Большой плюс: _полная_ история (к сожалению, под давлением фанатив git, это уже уходит в историю)
> А можно тут подробнее: имеются ввиду squash commits?Думаю, примерно это и имелось в виду. Может, я и ошибаюсь, тоже интересны подробности от автора построения. rebase-ы c "дешёвыми" ветками (в т.ч. их _перестановкой_ на новую версию истории) в git-е делают редактирование, изменение и чистку истории простыми, доступными и быстрыми -- в отличие от прочих претендентов, которые [предположительно] этого не делают и не позволяют от слова совсем. Но! При редактировании _истории_-то как раз история редактирлования :D истории не записывается и не сохраняется (ну, есть reflog, да. но как-то не то.... commit-мессаджи вообще придумали трусы...) ... м-м-м... понять рекурсию... Стоп!
[U]git[/U]: Минус: Не сохраняется история редактирования истории.
Все на Ртуть.
>[оверквотинг удален]
> интересны подробности от автора построения. rebase-ы c "дешёвыми" ветками (в
> т.ч. их _перестановкой_ на новую версию истории) в git-е делают редактирование,
> изменение и чистку истории простыми, доступными и быстрыми -- в отличие
> от прочих претендентов, которые [предположительно] этого не делают и не позволяют
> от слова совсем. Но! При редактировании _истории_-то как раз история редактирлования
> :D истории не записывается и не сохраняется (ну, есть reflog, да.
> но как-то не то.... commit-мессаджи вообще придумали трусы...) ... м-м-м... понять
> рекурсию... Стоп!
> [U]git[/U]: Минус: Не сохраняется история редактирования истории.
> Все на Ртуть.В mercurial уже тоже есть histedit. Phases - защита от дурака. В git я локально что хочу то и ворочу, а push могу делать только законченной версии фичи в виде серии последовательных коммитов, так что сервер защитить можно вполне от редактирования истории. А вот отсутствие легковесных веток в mercurial - огромный недостаток.
Имеетеся ввиду, что работая с git, все комиты делаются локально, затем выполняется pull, rebase master и rebase со слитием всех локальных комитов в один, коротый потом push'иться в головное хранилище, дабы там сделать merge fast-forward. К сожалению, это довольно распространённая практика.
В hg, до недавнего времени, это было сделать возможно, но не просто. Push'или и сливали всю ветку, что позволяло стороннему человеку понять ход развития мысли.
> rebase со слитием всех локальных комитов в одинСтоп. Зачем?
>> rebase со слитием всех локальных комитов в один
> Стоп. Зачем?То ли он экономит место на дискете, то ли со времён CVS комитит фичи только из патча (одного) в е-мейле, то ли ... Не связано ли это с Delphi? Или с РЖД? С виндой??!
А! Знаю!! "git — [...] Минусы: 1) нелогичность". БожежтымойжежЪ.
---Всем https://www.youtube.com/results?search_query=torvalds+git чаю.
Мне это тоже было интересно. Ответ я получил такой: чтоб была гладкая история и было видно в каком комите какая фича вводилась. Лично для меня, это ниразу не аргумент, но спорить с работодателем было несруки.
Мне не понравился hg тем, что в нём список всех веток и тагов с их хешами коммитов находится в текстовом файле, который (внимание!) тоже находится под контролем версий.
Создание новой ветки приводит к изменению этого файла и требует коммита. Создание тега так же.
А когда делаются push/pull, так там вообще приходится этот файл мержить, так как конфликты даже в нём возможны.
> Ещё понимаю переход hg->git, но обратный.. не разумею ... попробовал hg и втянулся ... очень приятно ... продуманно. Как в питонеВ этом заключается вся суть пользователей hg и самого hg - помойка и сумбур в голове.
Меркуриал ни в каком виде не является продуманной DVCS, тут больше подходит "передуманный". Например, изначально hg был модульным так, что без мозготраха нельзя было даже зажечь цвета в diff - нужно было готовить модуль и делать специальный алиас с другим названием команды (лол ... цвета для diff так и остались модулем color, только теперь не нужно делать алиас для команды). Особенно удивляла причина согласно которой дизайнеры ртути считали это правильным, ~ diff должен для всех выглядить одинаково чтобы его можно было использовать в скриптах. Нагородить грёбанные модули догадались, а поделить команды на пользовательские и технические не шмогли. Такая беда была со многими другими стандартными фичами, но в остальных случаях ещё нужно было руками выкачивать сами модули хер знает откуда...
Время шло и мало-помалу до идиотов доходило, что с такой модульностью жить нельзя. Но полностью спрятать атавизм под капот ума опять таки не хватило .. на текущий день все основные модули поставляются с mercurial, но фичи всё равно нужно явно включать в конфиге.
Кроме этого неверно выбранная стратегия разработки, т.е. попытка отстраниться от дизайна фич приложения через модули, привела к пересечению функционала в разных модулях. Например, чтобы получить функционал git-овго rebase в mercurial нужно сразу три модуля - rebase, mq и histedit .. и даже с ними не получается полного функционала и удобного к нему интерфейса. А сколько ещё есть экспериментальных модулей делающих одно и тоже...
Аналогичная ситуация случилась с ветками - их нагородили несколько видов с разными свойствами и умудрились привязать сами коммиты к некоторым типам веток. В общем, снова люди решали проблемы которых на самом деле не было, сделали overengineering.
Есть ещё комичные примерны дизайна в этой убогой vcs, прямо в новости пишут:
> Добавлено экспериментальное расширение automv, которое автоматизирует определение фактов переименования и копирования файлов в репозитории ...
VCS, ориентированная на работу исходниками, всё ещё оперирует понятиями перемещения файла, а не кусков текста. Раньше если как-то не так перемещаешь файл (не через hg mv), то ртуть теряет его историю .. а теперь вот впилили костыль, но всё равно hg не разрулит разрез файла на несколько, склейку файлов в один или суперпозицию этих изменений. Всё это нужно для нормальной истории и blame/annotate.
В итоге hg не имеет консистентного стабильного функционала и имеет меньшую гибкость по сравнению с прямым конкуретном. В этом поединке hg ушло в историю вполне заслуженно.
>> Ещё понимаю переход hg->git, но обратный.. не разумею ... попробовал hg и втянулся ... очень приятно ... продуманно. Как в питоне
> Например, изначально hg был модульным так, что без мозготраха нельзя было даже зажечь цвета в diff - нужно было готовить модуль и делать специальный алиас с другим названием команды (лол ... цвета для diff так и остались модулем color, только теперь не нужно делать алиас для команды).Давайте тогда уже вспомним, что команда commit в гите существовала не всегда. Или что в 2016 году у каждого пользователя гита свой собственный набор алиасов различной степени кривости. Хотя что это я — ведь это же Совершенно Другое Дело, потому что это же целый Гит Освящённый Сиянием Святого Торвольца.
> Время шло и мало-помалу до идиотов доходило, что с такой модульностью жить нельзя. Но полностью спрятать атавизм под капот ума опять таки не хватило .. на текущий день все основные модули поставляются с mercurial, но фичи всё равно нужно явно включать в конфиге.
Как бы вопрос умолчаний: самое главное — версионировать исходники — hg умеет без никаких плагинов.
> Кроме этого неверно выбранная стратегия разработки, т.е. попытка отстраниться от дизайна фич приложения через модули, привела к пересечению функционала в разных модулях. Например, чтобы получить функционал git-овго rebase в mercurial нужно сразу три модуля - rebase, mq и histedit .. и даже с ними не получается полного функционала и удобного к нему интерфейса.
А может ли быть так, что это как раз git rebase — гибрид ужа с ежом, запихивание в одну команду собственно rebase и переупорядочивание коммитов… /* philosoraptor.jpg */ Да нет, глупости какие, разработчики Git не могут ошибаться.
> А сколько ещё есть экспериментальных модулей делающих одно и тоже...
Да, сколько?
> Аналогичная ситуация случилась с ветками - их нагородили несколько видов с разными свойствами и умудрились привязать сами коммиты к некоторым типам веток. В общем, снова люди решали проблемы которых на самом деле не было, сделали overengineering.
Это, конечно же, враньё. Ветки были всегда, просто без ограничений как в гите (какой ужас! да как они посмели!). Потом запилился плагин bookmarks с гитоподобными ветками, потом его положили в дистрибутив, потом вмержили в ядро. Ну да, хорошая годная функциональность, бывает.
> Есть ещё комичные примерны дизайна в этой убогой vcs, прямо в новости пишут:
>> Добавлено экспериментальное расширение automv, которое автоматизирует определение фактов переименования и копирования файлов в репозитории ...
> VCS, ориентированная на работу исходниками, всё ещё оперирует понятиями перемещения файла, а не кусков текста. Раньше если как-то не так перемещаешь файл (не через hg mv), то ртуть теряет его историю .. а теперь вот впилили костыль, но всё равно hg не разрулит разрез файла на несколько, склейку файлов в один или суперпозицию этих изменений. Всё это нужно для нормальной истории и blame/annotate.Во-первых, никто, кроме SemanticMerge и аналогов такое не разрулит. Во-вторых, вот не будут имена файлов нести семантической нагрузки — тогда и поговорим.
К вопросу о комичных эпизодах:
* у вас в гите «история» зависит от ключей команды diff и количества изменений
* diff --git умеет записывать перемещение/копирование файлов, но при импорте в git эта информация теряетсяНет-нет, я всё понимаю — это Соверщенно Другое Дело.
> В итоге hg не имеет консистентного стабильного функционала
Враньё: версионировать исходники.
> имеет меньшую гибкость по сравнению с прямым конкуретном.
Враньё как минимум в количестве и качестве extension points.
> В этом поединке hg ушло в историю вполне заслуженно.
да-да, вот только караван всё идёт почему-то. Вероятно потому, что на стороне hg про поединок и не в курсе.
> Давайте тогда уже вспомним, что команда commit в гите существовала не всегдаДа, давай вспомним - существовала с первых месяцев разработки, это конец 2005-го. Модульный пц в hg, который я описываю выше, был как минимум до 2011 и всё ещё присутствует в некотором виде.
> Или что в 2016 году у каждого пользователя гита свой собственный набор алиасов различной степени кривости.
Это твои фантазии. У каждого пользователя в лучшем случае пара алиасов для git log под свой вкус, в общем как и у пользователей hg.
> Хотя что это я — ведь это же Совершенно Другое Дело, потому что это же целый Гит Освящённый Сиянием Святого Торвольца.
Понимаешь в чём дело .. сарказм это форма искусства, а технический ~ ещё мозгов требует и аналитический ум. Нельзя просто так сморозить какую-то чушь на техническую тему и не выглядеть так жалко, как ты сейчас.
> Как бы вопрос умолчаний: самое главное — версионировать исходники — hg умеет без никаких плагинов.
У человека что самое главное? Пусть будет голова - ей он иногда думает и регулярно кушает в неё. Но если отделить голову от остального тела, то останется ли от неё прок? Едва ли.
С SCM ситуация точно такая же - движок это хорошо, но консистентность и удобство интерфейса к нему имеют не меньшее значение. Тем более внутренности hg сами по себе не уникальны и не представляют никакого интереса вне mercurial'а.
Тебя, кстати, не напрягает, что с тобой приходится нянчиться как с ребёнком и разжёвывать очевидные взрослым людям вещи?
> А может ли быть так, что это как раз git rebase — гибрид ужа с ежом, запихивание в одну команду собственно rebase и переупорядочивание коммитов
Если присмотреться к {rebase, mq, histedit}, то можно увидеть что все они внутри делают примерно одно и тоже, т.е. имеет место быть размножение реализации функционала. В частности histedit это тот же самый rebase с бОльшим кол-вом настроек. И mq тоже ребейз, но основанный на другой элементной базе (не на кишках hg .. почему собственно его хотят и хернуть из ртути).
В общем, rebase архитектурно является одной компонентой, а не тремя. И, ктобы мог подумать, интерфейсно эту компоненту тоже удобно представлять одной командой т.к. опции для разных сценариев применения rebase взаимодополняющие, а не исключающие друг друга.
> Да, сколько?
Опять в немощного будем играть? Посмотри сам в вики hg - их на порядки больше официальных.
> Это, конечно же, враньё. Ветки были всегда ...
Отлично, но речи не было что когда-то mercurial был совсем без веток...
> просто без ограничений как в гите (какой ужас! да как они посмели!).
В Git у веток никаких ограничений нет, так сказать легковесные ветки в терминологии hg. А на стандартные ветки mercurial как раз наложены некоторые существенные ограничения...
> Потом запилился плагин bookmarks с гитоподобными ветками, потом его положили в дистрибутив, потом вмержили в ядро
... А потом до разработчиков ртути чуточку дошло, что задуманные ими ветки не делают жизнь пользователя лучше и решили исправить архитектурный косяк .. но исправили в своём стиле - костыль появился в виде модуля. Тут уж не имеет значения что они его забрали у контрибьютеров.
> Во-первых, никто, кроме SemanticMerge и аналогов такое не разрулит.
Ничто не умеет так делать кроме того что умеет? Ну как бы да, с такой бессодержательной тавтологией не посморишь. Чтобы ты себе там не представлял о данной фичи, но в git она есть практически изначально .. а всё почему? git - the stupid _content tracker_.
> Во-вторых, вот не будут имена файлов нести семантической нагрузки — тогда и поговорим.
У тебя hg log и hg annotate научились понимать семантический смысл имён файлов? Ну чтож .. остаётся только порадоваться за дурь которой ты долбишься. Но в любом случае не понятно как такая замечательная фича подскажет annotate'у кем был сделан 7500 ра перемещённый кусок кода.
> у вас в гите «история» зависит от ключей команды diff и количества изменений
Примерно так и есть, это вполне логично - с учётом отслеживания перемещения кода история является субъективным понятием. Есть несколько точек зрения (алгоритмов) её построения и методы визуализации.
> diff --git умеет записывать перемещение/копирование файлов, но при импорте в git эта информация теряется
Как уже не тружно было догадаться, git это _content tracker_, а не _file tracker_, потому для него не существует понятия перемещения файла на уровне хранилища. Всё что diff показывает с перемещениями это эвристика предназначенная для пользователя, а не для другого git'а.
> Враньё: версионировать исходники.
Этот вопорс уже был разобран выше в секции 'SCM для детей дошкольного возраста'. Кратко, версионирование является функционалом библиотеки (движка) версионирования, а не DVCS.
> Враньё как минимум в количестве и качестве extension points.
В этом кроется ещё одно заблуждение чрезвычайно глупых людей которое выражается в вере в серебрянную пулю, или в существование очень простого решения сложной задачи. Разработчики hg приняли за такое решение твои extension points решив совсем отстраниться от дизайна консистентности и полноты функционала.
Но чудес не бывает, сложные задачи сами собой не решаются и вся история разработки mercurial достаточно красочно иллюстрирует это. Собственно, с этого я и начал текст выше.\
> да-да, вот только караван всё идёт почему-то. Вероятно потому, что на стороне hg про поединок и не в курсе.
Идущие на смерть приветствуют императора, альтернатив то у них всё равно нет.
>> Давайте тогда уже вспомним, что команда commit в гите существовала не всегда
> Да, давай вспомним - существовала с первых месяцев разработки, это конец 2005-го. Модульный пц в hg, который я описываю выше, был как минимум до 2011 и всё ещё присутствует в некотором виде.не commit, так rm или annotate — несущественно (публичная история гита начинается с big tools rename в 2005).
>> Или что в 2016 году у каждого пользователя гита свой собственный набор алиасов различной степени кривости.
> Это твои фантазии. У каждого пользователя в лучшем случае пара алиасов для git log под свой вкус, в общем как и у пользователей hg.ага, гугл по запросу "git aliases", следует понимать, тоже фантазирует:
* "The Ultimate Git Alias Setup · GitHub" https://gist.github.com/mwhite/6887990
* Must Have Git Aliases: Advanced Examples - Be Present Now http://durdn.com/blog/2012/11/22/must-have-git-aliases-advan.../
* lab 11 Aliases - Git Immersion http://gitimmersion.com/lab_11.htmlВпрочем, лучше будет предоставить слово счастливым пользователям: https://github.com/search?utf8=%E2%9C%93&q=al... (134К результатов)
Попытки этот разброд и шатание упорядочить святым апстримом, естественно, игнорируются.
>> Как бы вопрос умолчаний: самое главное — версионировать исходники — hg умеет без никаких плагинов.
> У человека что самое главное? Пусть будет голова - ей он иногда думает и регулярно кушает в неё. Но если отделить голову от остального тела, то останется ли от неё прок? Едва ли.Обожаю некорректные аналогии.
> С SCM ситуация точно такая же - движок это хорошо, но консистентность и удобство интерфейса к нему имеют не меньшее значение. Тем более внутренности hg сами по себе не уникальны и не представляют никакого интереса вне mercurial'а.
Хм, обычно «консистентность» и «удобство» в тредах за гит являются ругательством. Это, в принципе, понятно — исторически сложилось так, что нужно и полезно только и исключительно то, что в гите есть, а ненужно и вредно всё остальное. Соответственно, когда в гит притаскивают то, что в нём изначально отсутствовало, оно перестаёт быть ненужным и вредным и автоматически становится нужным и полезным.
> Тебя, кстати, не напрягает, что с тобой приходится нянчиться как с ребёнком и разжёвывать очевидные взрослым людям вещи?
А, так это вы хамить мне пытаетесь? Вам идёт. Но пробуйте тяжелее.
>> А может ли быть так, что это как раз git rebase — гибрид ужа с ежом, запихивание в одну команду собственно rebase и переупорядочивание коммитов
> Если присмотреться к {rebase, mq, histedit}, то можно увидеть что все они внутри делают примерно одно и тоже, т.е. имеет место быть размножение реализации функционала. В частности histedit это тот же самый rebase с бОльшим кол-вом настроек. И mq тоже ребейз, но основанный на другой элементной базе (не на кишках hg .. почему собственно его хотят и хернуть из ртути).mq работает с очередью патчей и показывает их как виртуальные changesets; rebase перемещает кусок графа версий; histedit манипулирует (переставить/удалить/поправить) changesetами из заданного диапазона. Как-то слишком приблизительно «одно и то же». Код под капотом может быть сколько угодно похож, но непонятно, почему это должно хоть сколько волновать пользователя.
> В общем, rebase архитектурно является одной компонентой, а не тремя. И, ктобы мог подумать, интерфейсно эту компоненту тоже удобно представлять одной командой т.к. опции для разных сценариев применения rebase взаимодополняющие, а не исключающие друг друга.
Проверочный вопрос — является ли «interactive "rebase"» неотъемлемой частью обычного rebase? Нет. Значит, histedit отдельно, а rebase отдельно.
>> Да, сколько?
> Опять в немощного будем играть? Посмотри сам в вики hg - их на порядки больше официальных.А я что, «бремя доказательства лежит на утверждающем». Олсо «на порядки» — это сколько именно?
>> просто без ограничений как в гите (какой ужас! да как они посмели!).
> В Git у веток никаких ограничений нет, так сказать легковесные ветки в терминологии hg.Конечно же, это не так. На каждую вершину графа версий репозитория должна ссылаться какая-нибудь ref, иначе git gc эту голову удалит. в hg же можно безопасно ветвиться от любой точки в истории, т.к. hg не решает за пользователя, какие изменения у него считать мусором, а какие — нет.
>> Потом запилился плагин bookmarks с гитоподобными ветками, потом его положили в дистрибутив, потом вмержили в ядро
> ... А потом до разработчиков ртути чуточку дошло, что задуманные ими ветки не делают жизнь пользователя лучше и решили исправить архитектурный косяк .. но исправили в своём стиле - костыль появился в виде модуля. Тут уж не имеет значения что они его забрали у контрибьютеров.Ух ты, живой телепат! Мало что мысли в реальном времени читает, так ещё и доступ к архиву имеет!
Вот подробный тред про «неправильное» ветвление в mercurial: https://news.ycombinator.com/item?id=11672259 (TL;DR hg branch действительно не годятся для feature branches, но отлично годятся для ongoing line of development; до bookmarks "feature branches" были просто ещё одной головой DAG версий, после — им стало можно давать имена, как в гите, ура, револю… а нет, показалось)
>> Во-первых, никто, кроме SemanticMerge и аналогов такое не разрулит.
> Ничто не умеет так делать кроме того что умеет? Ну как бы да, с такой бессодержательной тавтологией не посморишь. Чтобы ты себе там не представлял о данной фичи, но в git она есть практически изначально .. а всё почему? git - the stupid _content tracker_.git-log -L <start>,<end>:<file> штоле? Не отрицаю полезности, однако, [2013](https://github.com/git/git/commit/12da1d1f6ffcd546a892a33302...) при всём желании не тянет на «с самого начала».
Также в реальном мире нередко правят содержимое файла *одновременно* с его перемещением/копированием, и вот тут-то «тщательно выверенная» (ака «само выросло») абстракция протекает: гит начинает пытаться угадать (а при достаточном большом количестве различий — даже не начинает, просто делает вид, что старый файл удалили, а новый создали с ноля), что в куда переименовалось/скопировалось.
>> Во-вторых, вот не будут имена файлов нести семантической нагрузки — тогда и поговорим.
> У тебя hg log и hg annotate научились понимать семантический смысл имён файлов?Переформулирую: вот не будет разницы, как называется файл, в котором лежит трекаемый текст — тогда и поговорим. А пока что у вас абстракция по-прежнему течёт.
>> diff --git умеет записывать перемещение/копирование файлов, но при импорте в git эта информация теряется
> Как уже не тружно было догадаться, git это _content tracker_, а не _file tracker_, потому для него не существует понятия перемещения файла на уровне хранилища. Всё что diff показывает с перемещениями это эвристика предназначенная для пользователя, а не для другого git'а.Эвристика, если diff этот экспортирован из Git и файл был изменён и скопирован/перемещён. К счастью, возможность импорта/экспорта из/в diff --git не является прерогативой Git.
>> да-да, вот только караван всё идёт почему-то. Вероятно потому, что на стороне hg про поединок и не в курсе.
> альтернатив то у них всё равно нет.Это точно. Ведь git не является полноценной альтернативой Mercurial.
Не врите, go на github, и соответственно использует git а не mercurial.
Я так и не понял. Кто всё таки использует Mercurial?
NetBeans, OpenJDK, Mozilla.
Мозилла понемногу тоже на гитхабе сваливает
там пока RO зеркала, но хорошо было бы если свалят совсем.
Я юзаю. Этого достаточно?
Нет.
А Facebook?
Изя, зачем тебе Фисбук? Тебе же должно хватать ОпенЯДК.
Solaris
Хм, вот впору собирать как раз список проектов, сбежавших с меркуриала
Всегда рад новостям о Меркуриал - даже если я останусь последним его юзером, всё-равно не брошу! Потому что писан людьми для людей.
В принципе, ты прав: при конфликтах срать в проект файлами .orig и .rej и не убирать за собой - типичное для людей поведение.
> Устранена опасная уязвимость CVE-2016-3105, которая может привести к выполнению кода злоумышленника при выполнении конвертации Git-репозиториявсё зло - от git! :))
а вообще, в последнее время больше fossil пользуюсь, чем hg. с тех пор, как завезли нормальную тему для web ui - стало хорошо. нравится его распредвики, распредбактрекер и распредвсёостальное. не нравится необходимость всё время открыать/закрывать реп и маниакальная попытка перезаписать всё при новом открытии.
>тему для web uiхипстеры должны страдать
>>тему для web ui
> хипстеры должны страдатьв fossil были такие темы, по сравнению с которыми те сайты, которые я выкладывал на .narod.ru в прошлом веке - прекрасны ;)
фозил этот - бажный кусок софта.
Смешно. Может в твоей альтернативной вселенной еще и sqlite бажный?
Да ладно, он вполне дубов и для мелких проектов удобен. Но версионник в нынешнем мире - это прежде всего об интероперабельности и понятности для окружающих, поэтому - только Git. Плюс под него есть тулзы на любой вкус и масса экспириенса - можно что угодно наворотить.Хотя лично для меня Git с его индексом оказался как-то логичнее и удобнее CVS/SVN/hg/Fossil.
> ... на любой вкус и масса экспириенса - можно что угодно наворотить.И тут нашего Алёшу как всегда понесло. Наворотили уже достаточно, невпроворот уже сколько наворотили, и каждую неделю всё подворачивают. И тут ещё и Алёша с предложениями наворотить. Когда же вы уже угомонитесь наконец-то?
>как завезли нормальную тему для web ui -на нем все такие же траблы с написанием вики страниц если версия локально и версия на сервере - разные?
Если бы Mercurial поддерживал хорошее сжатие репы, как git gc --aggressive. А так если не git, то скорее fossil.Кстати, к проектам, которые ушли недавно с Mercurial на git, добавьте GHDL.
> Если бы Mercurial поддерживал хорошее сжатие репы, как git gc --aggressive. А
> так если не git, то скорее fossil.Читайте внимательнее! Ентерпрайсная версия 3.7 стала... [драма!] _быстрее_. И _отделилась_ от SUBJ! Очевидно B*) , ещё немного, и она перейдёт на git.
> OpenSolarisНет уже такого проекта... Есть Illumos, который использует Git.
Ха, как тут подсказывают, они чуток не дотерпели до события 9 мая, когда Меркурий будет проходить по диску Солнца.
>не дотерпели до события
>Меркурий будет проходитьНайди 8 отличий!
From Mueller English-Russian Dictionary [mueller7]:
mercurial
[mɜ:↗kjʊɜrɪɜl]
1. _a.
1) ртутный
2) живой, подвижный; деятельный
3) непостоянный
2. _n. ртутный препаратFrom Mueller English-Russian Dictionary [mueller7]:
Mercury
[↗mɜ:kjʊrɪ] _n.
1) римск. _миф. Меркурий
2) _астр. планета Меркурий
3) _шутл. посол; вестник (тж. в названиях газет)
Вообще-то ртуть в честь Меркурия (божества) и названа, если ты не знал.
> Вообще-то ртуть в честь Меркурия (божества) и названа, если ты не знал.Сгоняй на Олимп, выясни в честь кого его назвали, а то я не знал.
А раз знал - к чему цепляешься? Ну да, красивее было бы
> А раз знал - к чему цепляешься? Ну да, красивее было быТы не понял? Поясню: без разницы, кто чей папа, _значения_ совсем разные.
> Ты не понял? Поясню: без разницы, кто чей папа, _значения_ совсем разные.Значения событий и правда совсем разные, про mercurial, вот, неинтересно почти никому.
>> Ты не понял? Поясню: без разницы, кто чей папа, _значения_ совсем разные.
> Значения событий и правда совсем разные, про mercurial, вот, неинтересно почти никому.А... _Ты_ неправильно тролишь тех, кто не сумел в git. Вон там наверху - интересно.
>>не дотерпели до события
>>Меркурий будет проходить
> Найди 8 отличий!
> From Mueller English-Russian Dictionary [mueller7]:
> mercurial
> 3) непостоянныйУчёные-лингисты обнаружили ещё "перевод" (тэг: игра\ слов\ en):
| "mercurial" - Larry McVoy
| as in: [U]"Mercurial is thus named in Larry's honor. "[/U]
| -- http://lwn.net/Articles/686924/--
From Mueller English-Russian Dictionary [mueller7]:
fickle
[↗fɪkl] _a. непостоянный, переменчивый; ненадёжный> From Mueller English-Russian Dictionary [mueller7]:
> Mercury2O.P.: Ладно, ладно, это я не могу в саркзм. И в иронию.
> Ха, как тут подсказывают, они чуток не дотерпели до события 9 мая, когда Меркурий будет проходить по диску Солнца.у них расписание — https://www.mercurial-scm.org/wiki/TimeBasedReleasePlan