Доступен (https://www.mercurial-scm.org/wiki/Release4.0) релиз распределённой системы управления версиями Mercurial 4.0 (https://www.mercurial-scm.org/wiki/Release4.0). Выпуск 4.0 не связан внесением кардинальных изменений или новшеств, он лишь является следствием смены первой цифры в рамках используемой проектом десятичной схемы нумерации, в соответствии с которой после 3.9 следует версия 4.0, а не 3.10. Код Mercurial написан на языке Python (требующие высокой производительности части оформлены в виде модулей на Си) и распространяется под лицензией GPLv2+. Среди проектов, использующих Mercurial, можно выделить следующие: Mozilla, OpenOffice.org, OpenSolaris, NetBeans, OpenJDK, Nginx, Xine и W3C.Основные изменения (https://www.mercurial-scm.org/wiki/WhatsNew):
- В команды 'hg version', 'hg grep' и 'hg config' добавлена экспериментальная поддержка фильтра formatter для преобразования списка в произвольный формат;- Добавлено новое ключевое слово termwidth и функции для работы с шаблонами mod(a, b) и relpath(path);
- Реализована возможность применения в шаблонах простых арифметических операций, например "termwidth - 10";
- В функцию выбора ревизии follow() добавлен параметр startrev;
- В сценарии автодополнения для bash обеспечена возможность пропуска аргументов, приводящих к ресурсоёмким операциям 'hg status', в случае установки переменной окружения;
- Внесены изменения в код отслеживания операций перемещения и копирования файлов, позволяющие гарантировать сохранение информации о копировании и перемещении при выполнении команд, подобных 'hg graft';
- Значительно улучшена поддержка Python 3;
- Увеличена производительность zlib в hgweb и добавлена возможность выбора уровня сжатия через опцию server.zliblevel.URL: https://www.mercurial-scm.org/wiki/WhatsNew#Mercurial_4.0_.2...
Новость: http://www.opennet.me/opennews/art.shtml?num=45415
Отличная новость. Проект живет и развивается. И python3 поддержку наконец пилят. Использую в разных проектах Mercurial. На работе много раз он был (gamedev и требуется largefiles). Шикарная вещь. А его GUI (TortoiseHg) в 100 раз лучше любого Git'ового. Т.к. он официальный и работает на всех платформах, а не только на виндах.
> Отличная новость.
>А его GUI (TortoiseHg)Согласен! Виндузятники должны с... ну, то есть им -- самое то.
Good commandline + graphical UI in one package.
> Good commandline + graphical UI in one package.Отличное гетто для виндовых инвалидов с их переклином на гуе, чтобы к нам не лезли.
Отличная рскв. Удачи им и tortoise-hg.
лучше бы stage area добавили, чтобы не мудохаться в консоли с фильтрами при коммите
можно https://www.mercurial-scm.org/wiki/CrecordExtension#For_Merc... пользоваться, если совсем неймётся — можно MQ,
хм, интересно, спасибо. слышал только об MQ, но как-то напрягало ставить расширения для того, что могло быть first-class citizen. а crecord делает бекапы как это делает strip?
> как-то напрягало ставить расширения для того, что могло быть first-class citizenmq уже сто лет в коробке, поэтому не ставить, а включать
> а crecord делает бекапы как это делает strip?
нет, оно историю не редактирует
> Выпуск 4.0 не связан внесением кардинальных изменений или новшеств, он лишь является следствием смены первой цифры в рамках используемой проектом десятичной схемы нумерации, в соответствии с которой после 3.9 следует версия 4.0, а не 3.10.Это такая специальная схема нумерации, которая требует сопровождать каждую смену первой цифры пояснительным текстом (см. выше). Ну потому что надо же, чтобы было о чем писать в новостях о релизе.
А следующая версия по-видимому будет называться 4.09999999999999964473, ибо они вместо пары интов -- один флоат используют.
У них же десятичная схема, так что не флот, а десимал. Поэтому все хорошо
> У них же десятичная схема, так что не флот, а десимал.numeric(2.1) имени проблемы Y2K ? Традиции, научный подход, не абы что. Это прекрасно!
>Поэтому все хорошо
После Git вообще идет отторжение всех остальных VCS. Это норм?
Нет, красноглазость. Должна пройти с опытом.
> После Git вообще идет отторжение всех остальных VCS. Это норм?фанатизм?
У меня первой DVCS была Mercurial, отторжения к git в целом у меня нет, только снисходительность :)
> У меня первой DVCS была Mercurial, отторжения к git в целом у
> меня нет, только снисходительность :)Снисходительность скрипткидиза к матерым разработчикам - это так забавно выглядит :)
> После Git вообще идет отторжение всех остальных VCS. Это норм?После Git (первой dvcs, кстати) идёт отторжение Git. Это норм?
> После Git (первой dvcs, кстати) идёт отторжение Git. Это норм?Для тебя - да.
>> После Git вообще идет отторжение всех остальных VCS. Это норм?
> После Git (первой dvcs, кстати) идёт отторжение Git. Это норм?Для вас обоих: ответ зависит от определения нормы. Где-то так: у вас обоих (я сам тож к #1 присоединяюсь :/) частично/_всё_ "норм", но с ниасиленными кундштюками будут проблемы-напряги, когда и если. Вот меня, например, просто выворачивает детать что-то за рамками svn {ci|st|up} -- и это приемлемая для меня "норма"...
да, норм.
После перехода с CVS на SVN, с SVN на Mercurial - Git совсем не торт. Набор наскоро состряпанных за полчаса на коленке заплаток. Можно было потратить полчаса на проработку юзабилити, прежде чем сляпать git.
> После перехода с CVS на SVN, с SVN на Mercurial - Git
> совсем не торт. Набор наскоро состряпанных за полчаса на коленке заплаток.
> Можно было потратить полчаса на проработку юзабилити, прежде чем сляпать git.Они работают над этим вашим "юзибилити" -- уже год-два-три, не знаю уж, половина ченджлога "мы тут накостылили для венды подпорочку -- уж теперь-то! ух-х-х...". Уже скоро!
Полачаса на коленке? А вот некому Линусу Торвальдсу понадобилось около месяца на первый приемлемый вариант. Ну если ты у нас такой мегапрограммист, то может за пару недель аналог линукс ядра наваяешь?
Линус на этом видео[1] говорит, что менее двух недель.
> Линус на этом видео[1] говорит, что менее двух недель.
> [1] https://www.youtube.com/watch?v=4XpnKHJAok8А вот был бы он опеннетчиком -- наваял бы за пару дней, от скуки, между делом -- ожидая очередной новости или ответа на мудрый комментарий! )
> Линус на этом видео[1] говорит, что менее двух недель.Это потому, что у него гвидобейсика не было. А так бы за вечер управился.
Тут смотря какой момент считать точкой готовности.
The development of Git began on 3 April 2005.[19] Torvalds announced the project on 6 April;[20] it became self-hosting as of 7 April.[19] The first merge of multiple branches took place on 18 April.[21] Torvalds achieved his performance goals; on 29 April, the nascent Git was benchmarked recording patches to the Linux kernel tree at the rate of 6.7 per second.
То есть при желании можно посчитать готовым и за 4 дня или 15. Однако требование скорости было крайне важным, поэтому я посчитал готовностью то, что было через 26 дней.
>можно посчитать готовым и за 4 дня или 15.
> то, что было через 26 дней.В среднем по больнице -- те же самые 2 недели! %)
Оно кому-то нужна? Мир выбрал git, точка. Дорога вслед за bazaar.
Миллион леммингов не могут что? - Выбрать гит. Спасибо что напомнил нам об этом.
и Windows.
А вот перепишут на Rust - глядишь и взлетит
Нееее, common path is: python -> Go ...
> Нееее, common path is: python -> Go ...Хипстерам нравится переписывать софт, меньше трех раз - вообще ни о чем. Поэтому хипстеры из дропбокса переписывают на rust. Ждем когда их долбанет все переписать на java, чтоли. Ведь это круто и энтерпрайзно, так сан сказал.
> А вот перепишут на Rust - глядишь и взлетитС каких это пор хруст взлетел? :)
> Оно кому-то нужна? Мир выбрал git, точка. Дорога вслед за bazaar.Думаешь дедушка Столман их, дивисиэсы эти упадочные, коллекционировать пачками будет?! Типа в пику Л.Т.?... Или что, в какой "всдед", поясни? //саммоним пользователей б-з-р=а, явитесь!
Такое вот стадное мышление исключает всякий прогресс. Популярное редко оказывается лучшим, всегда следует искать альтернативы, а не тупо следовать выбору толпы.
Ну интересно какого прогресса ты достигнешь разместим проект вместо github на маргинальном хостинге с hg, где и регистрироваться-то никто не будет.
> Ну интересно какого прогресса ты достигнешь разместим проект вместо github на маргинальном
> хостинге с hg, где и регистрироваться-то никто не будет.pypy пока живет и не кашляет на хостинге с hg.
Думаю, от переноса cpython на гитхабчик - тоже лучше не будет. Ибо большинство местной живности свой интеллектуальный потолок пробило уже собственно регистрацией.
> Такое вот стадное мышление исключает всякий прогресс. Популярное редко оказывается лучшим,Ты можешь попытаться переписываться с нами по лучшему сетевому протоколу, который придумаешь сам. Используя какой-нибудь совершенный синтетический язык вместо кривоватого русского. Мы правда этот язык не знаем, но тебя это смущать не должно. Сразу после того как разберешься как запитать от розеток с нестандартным напряжением твои компьютеры и сумеешь портировать на экзотичный процессор, который есть только у тебя вон ту необычную операционку и хоть какой-нибудь софт под нее.
Чего мне не хватает - так это git repack (который вызывается при git gc --aggressive). Иногда, размер .git уменьшается в разы! А .hg растёт и растёт.
> А .hg растёт и растёт.Менять историю - плохая практика. Поэтому .hg сохраяет всё, в том числе ошибочные действия, которые можно откатить.
Зелен виноград.
> Менять историю - плохая практика. Поэтому .hg сохраяет всё, в том числе ошибочные действия, которые можно откатить.сохранять всё -- плохая практика. поэтому git имеет возможность делать git repack, и в частности во время выполнения git gc --aggressive
> Менять историю - плохая практика.Возможно тебе это ничего не говорит, но там разговор про "repack" а не "rebase".
>> Менять историю - плохая практика.
> Возможно тебе это ничего не говорит, но там разговор про "repack" а
> не "rebase".Они там у себя в ртути бережно перечитывают объекты в сторадже, на который уже нет ссылок. ...и ностальгируют!
Со временем может прийти понимание, что удалённое и оптимизированное как раз и не было ошибочным. hg восстановит, а в git придёться писать сызнова. Весело.
> Менять историю - плохая практика.Твоё министерство образования с тобой не согласно.
Менять историю в локальной рабочей копии - и можно, и нужно. Никому не интересны ваши ошибки на тернистом пути к конечному результату.Нужно ли менять историю изменений уже опубликованных изменений? Из соображений элементарной вежливости, пожалуй не стоит, кроме тех случаев, когда над душой стоит какое-нибудь лицо в официальной роли и помахивает перед носом не менее официальной бумажкой. Тогда - придётся :)