The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Выпуск распределённой системы управления версиями Mercurial 4.0

02.11.2016 17:32

Доступен релиз распределённой системы управления версиями Mercurial 4.0. Выпуск 4.0 не связан внесением кардинальных изменений или новшеств, он лишь является следствием смены первой цифры в рамках используемой проектом десятичной схемы нумерации, в соответствии с которой после 3.9 следует версия 4.0, а не 3.10. Код Mercurial написан на языке Python (требующие высокой производительности части оформлены в виде модулей на Си) и распространяется под лицензией GPLv2+. Среди проектов, использующих Mercurial, можно выделить следующие: Mozilla, OpenOffice.org, OpenSolaris, NetBeans, OpenJDK, Nginx, Xine и W3C.

Основные изменения:

  • В команды '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.


  1. Главная ссылка к новости (https://www.mercurial-scm.org/...)
  2. OpenNews: Facebook работает над реализацией сервера Mercurial на языке Rust
  3. OpenNews: Релиз распределённой системы управления версиями Mercurial 3.9
  4. OpenNews: Релиз распределённой системы управления версиями Mercurial 3.8
  5. OpenNews: Создатель системы управления версиями Mercurial передаёт проект в руки сообщества
  6. OpenNews: В Git и Mercurial устранена критическая уязвимость, проявляющаяся в Windows и OS X
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/45415-mercurial
Ключевые слова: mercurial
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (51) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 19:11, 02/11/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Отличная новость. Проект живет и развивается. И python3 поддержку наконец пилят. Использую в разных проектах Mercurial. На работе много раз он был (gamedev и требуется largefiles). Шикарная вещь. А его GUI (TortoiseHg) в 100 раз лучше любого Git'ового. Т.к. он официальный и работает на всех платформах, а не только на виндах.
     
     
  • 2.8, Andrey Mitrofanov (?), 21:05, 02/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Отличная новость.
    >А его GUI (TortoiseHg)

    Согласен! Виндузятники должны с... ну, то есть им -- самое то.

     
     
  • 3.34, ШШШШ (?), 13:48, 03/11/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Good commandline + graphical UI in one package.
     
     
  • 4.49, Аноним (-), 22:51, 04/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Good commandline + graphical UI in one package.

    Отличное гетто для виндовых инвалидов с их переклином на гуе, чтобы к нам не лезли.

     

  • 1.2, Аноним (-), 19:24, 02/11/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Отличная рскв. Удачи им и tortoise-hg.
     
  • 1.3, Аноним (-), 19:46, 02/11/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    лучше бы stage area добавили, чтобы не мудохаться в консоли с фильтрами при коммите
     
     
  • 2.12, develop7 (ok), 00:06, 03/11/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    можно https://www.mercurial-scm.org/wiki/CrecordExtension#For_Mercurial_v3.8.1_and_l пользоваться, если совсем неймётся — можно MQ,
     
     
  • 3.14, Аноним (-), 00:13, 03/11/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    хм, интересно, спасибо. слышал только об MQ, но как-то напрягало ставить расширения для того, что могло быть first-class citizen. а crecord делает бекапы как это делает strip?
     
     
  • 4.16, develop7 (ok), 01:03, 03/11/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > как-то напрягало ставить расширения для того, что могло быть first-class citizen

    mq уже сто лет в коробке, поэтому не ставить, а включать

    > а crecord делает бекапы как это делает strip?

    нет, оно историю не редактирует


     

  • 1.4, Аноним (-), 20:05, 02/11/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    > Выпуск 4.0 не связан внесением кардинальных изменений или новшеств, он лишь является следствием смены первой цифры в рамках используемой проектом десятичной схемы нумерации, в соответствии с которой после 3.9 следует версия 4.0, а не 3.10.

    Это такая специальная схема нумерации, которая требует сопровождать каждую смену первой цифры пояснительным текстом (см. выше). Ну потому что надо же, чтобы было о чем писать в новостях о релизе.

     
     
  • 2.24, Мяут (ok), 03:09, 03/11/2016 [^] [^^] [^^^] [ответить]  
  • +3 +/
    А следующая версия по-видимому будет называться 4.09999999999999964473, ибо они вместо пары интов -- один флоат используют.
     
     
  • 3.25, trolleybus (?), 10:43, 03/11/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    У них же десятичная схема, так что не флот, а десимал. Поэтому все хорошо
     
     
  • 4.27, Andrey Mitrofanov (?), 11:01, 03/11/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > У них же десятичная схема, так что не флот, а десимал.

    numeric(2.1) имени проблемы Y2K ? Традиции, научный подход, не абы что. Это прекрасно!

    >Поэтому все хорошо

     

  • 1.5, Просто Анон (?), 20:12, 02/11/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    После Git вообще идет отторжение всех остальных VCS. Это норм?
     
     
  • 2.6, Клапауций (ok), 20:57, 02/11/2016 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Нет, красноглазость. Должна пройти с опытом.
     
  • 2.7, Anonymous1 (?), 20:59, 02/11/2016 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > После Git вообще идет отторжение всех остальных VCS. Это норм?

    фанатизм?

     
  • 2.9, Cykooz (ok), 21:08, 02/11/2016 [^] [^^] [^^^] [ответить]  
  • +5 +/
    У меня первой DVCS была Mercurial, отторжения к git в целом у меня нет, только снисходительность :)
     
     
  • 3.50, Аноним (-), 22:53, 04/11/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > У меня первой DVCS была Mercurial, отторжения к git в целом у
    > меня нет, только снисходительность :)

    Снисходительность скрипткидиза к матерым разработчикам - это так забавно выглядит :)

     
  • 2.17, develop7 (ok), 01:05, 03/11/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > После Git вообще идет отторжение всех остальных VCS. Это норм?

    После Git (первой dvcs, кстати) идёт отторжение Git. Это норм?

     
     
  • 3.19, Led (ok), 01:28, 03/11/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > После Git (первой dvcs, кстати) идёт отторжение Git. Это норм?

    Для тебя - да.

     
  • 3.28, Andrey Mitrofanov (?), 11:08, 03/11/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> После Git вообще идет отторжение всех остальных VCS. Это норм?
    > После Git (первой dvcs, кстати) идёт отторжение Git. Это норм?

    Для вас обоих: ответ зависит от определения нормы. Где-то так: у вас обоих (я сам тож к #1 присоединяюсь :/) частично/_всё_ "норм", но с ниасиленными кундштюками будут проблемы-напряги, когда и если.  Вот меня, например, просто выворачивает детать что-то за рамками svn {ci|st|up} -- и это приемлемая для меня "норма"...

     
  • 2.18, all_glory_to_the_hypnotoad (ok), 01:08, 03/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    да, норм.
     
  • 2.22, Вареник (?), 02:34, 03/11/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    После перехода с CVS на SVN, с SVN на Mercurial - Git совсем не торт. Набор наскоро состряпанных за полчаса на коленке заплаток. Можно было потратить полчаса на проработку юзабилити, прежде чем сляпать git.
     
     
  • 3.29, Andrey Mitrofanov (?), 11:11, 03/11/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > После перехода с CVS на SVN, с SVN на Mercurial - Git
    > совсем не торт. Набор наскоро состряпанных за полчаса на коленке заплаток.
    > Можно было потратить полчаса на проработку юзабилити, прежде чем сляпать git.

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

     
  • 3.33, angra (ok), 12:19, 03/11/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Полачаса на коленке? А вот некому Линусу Торвальдсу понадобилось около месяца на первый приемлемый вариант. Ну если ты у нас такой мегапрограммист, то может за пару недель аналог линукс ядра наваяешь?
     
     
  • 4.39, KonstantinB (ok), 16:50, 03/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Линус на этом видео[1] говорит, что менее двух недель.

    [1] https://www.youtube.com/watch?v=4XpnKHJAok8

     
     
  • 5.40, Аноним (-), 17:40, 03/11/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Линус на этом видео[1] говорит, что менее двух недель.
    > [1] https://www.youtube.com/watch?v=4XpnKHJAok8

    А вот был бы он опеннетчиком -- наваял бы за пару дней, от скуки, между делом -- ожидая очередной новости или ответа на мудрый комментарий! )


     
  • 5.43, Led (ok), 22:37, 03/11/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Линус на этом видео[1] говорит, что менее двух недель.

    Это потому, что у него гвидобейсика не было. А так бы за вечер управился.

     
  • 5.44, angra (ok), 01:19, 04/11/2016 [^] [^^] [^^^] [ответить]  
  • +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 дней.
     
     
  • 6.55, Andrey Mitrofanov (?), 14:13, 06/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    >можно посчитать готовым и за 4 дня или 15.
    > то, что было через 26 дней.

    В среднем по больнице -- те же самые 2 недели! %)

     

  • 1.10, Аноним (-), 22:13, 02/11/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    Оно кому-то нужна? Мир выбрал git, точка. Дорога вслед за bazaar.
     
     
  • 2.11, myhand (ok), 23:42, 02/11/2016 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Миллион леммингов не могут что? - Выбрать гит.  Спасибо что напомнил нам об этом.
     
  • 2.13, Alexey (??), 00:09, 03/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    и Windows.
     
  • 2.15, IB (?), 01:00, 03/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    А вот перепишут на Rust - глядишь и взлетит
     
     
  • 3.20, . (?), 02:01, 03/11/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Нееее, common path is: python -> Go ...
     
     
  • 4.47, Аноним (-), 22:46, 04/11/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Нееее, common path is: python -> Go ...

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

     
  • 3.23, Вареник (?), 02:36, 03/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > А вот перепишут на Rust - глядишь и взлетит

    С каких это пор хруст взлетел? :)

     
  • 2.30, Andrey Mitrofanov (?), 11:14, 03/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Оно кому-то нужна? Мир выбрал git, точка. Дорога вслед за bazaar.

    Думаешь дедушка Столман их, дивисиэсы эти упадочные, коллекционировать пачками будет?! Типа в пику Л.Т.?... Или что, в какой "всдед", поясни?  //саммоним пользователей б-з-р=а, явитесь!

     
  • 2.37, Аноним (-), 15:20, 03/11/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Такое вот стадное мышление исключает всякий прогресс. Популярное редко оказывается лучшим, всегда следует искать альтернативы, а не тупо следовать выбору толпы.
     
     
  • 3.41, Аноним (-), 21:39, 03/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Ну интересно какого прогресса ты достигнешь разместим проект вместо github на маргинальном хостинге с hg, где и регистрироваться-то никто не будет.
     
     
  • 4.45, myhand (ok), 11:56, 04/11/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Ну интересно какого прогресса ты достигнешь разместим проект вместо github на маргинальном
    > хостинге с hg, где и регистрироваться-то никто не будет.

    pypy пока живет и не кашляет на хостинге с hg.

    Думаю, от переноса cpython на гитхабчик - тоже лучше не будет.  Ибо большинство местной живности свой интеллектуальный потолок пробило уже собственно регистрацией.

     
  • 3.48, Аноним (-), 22:49, 04/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Такое вот стадное мышление исключает всякий прогресс. Популярное редко оказывается лучшим,

    Ты можешь попытаться переписываться с нами по лучшему сетевому протоколу, который придумаешь сам. Используя какой-нибудь совершенный синтетический язык вместо кривоватого русского. Мы правда этот язык не знаем, но тебя это смущать не должно. Сразу после того как разберешься как запитать от розеток с нестандартным напряжением твои компьютеры и сумеешь портировать на экзотичный процессор, который есть только у тебя вон ту необычную операционку и хоть какой-нибудь софт под нее.

     

  • 1.21, Андрей (??), 02:23, 03/11/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Чего мне не хватает - так это git repack (который вызывается при git gc --aggressive). Иногда, размер .git уменьшается в разы! А .hg растёт и растёт.
     
     
  • 2.26, iZEN (ok), 10:47, 03/11/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > А .hg растёт и растёт.

    Менять историю - плохая практика. Поэтому .hg сохраяет всё, в том числе ошибочные действия, которые можно откатить.

     
     
  • 3.31, Аноним (-), 11:15, 03/11/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Зелен виноград.
     
  • 3.32, XXXasd (ok), 11:19, 03/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Менять историю - плохая практика. Поэтому .hg сохраяет всё, в том числе ошибочные действия, которые можно откатить.

    сохранять всё -- плохая практика. поэтому git имеет возможность делать git repack, и в частности во время выполнения git gc --aggressive

     
  • 3.35, Аноним (-), 14:41, 03/11/2016 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Менять историю - плохая практика.

    Возможно тебе это ничего не говорит, но там разговор про "repack" а не "rebase".

     
     
  • 4.38, Andrey Mitrofanov (?), 15:38, 03/11/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> Менять историю - плохая практика.
    > Возможно тебе это ничего не говорит, но там разговор про "repack" а
    > не "rebase".

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

     
     
  • 5.51, iZEN (ok), 10:51, 05/11/2016 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Со временем может прийти понимание, что удалённое и оптимизированное как раз и не было ошибочным. hg восстановит, а в git придёться писать сызнова. Весело.
     
  • 3.42, Led (ok), 22:33, 03/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Менять историю - плохая практика.

    Твоё министерство образования с тобой не согласно.

     
  • 3.46, Клапауций (ok), 19:19, 04/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Менять историю в локальной рабочей копии - и можно, и нужно. Никому не интересны ваши ошибки на тернистом пути к конечному результату.

    Нужно ли менять историю изменений уже опубликованных изменений? Из соображений элементарной вежливости, пожалуй не стоит, кроме тех случаев, когда над душой стоит какое-нибудь лицо в официальной роли и помахивает перед носом не менее официальной бумажкой. Тогда - придётся :)

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру