LINUX.ORG.RU

Mercurial 1.7

 , ,


0

1

1-го ноября вышла новая версия распределенной системы управления исходным кодом Mercurial 1.7.

В новой версии разработчики внесли изменения в следующие компоненты программы:

  • Ядро:
    • filelog: улучшена производительность cmp;
    • setup/hg: Mercurial теперь всегда загружается из каталога, куда был установлен;
    • setup: более простые сообщения об ошибке при отсутствии заголовочных файлов Python;
    • store: новый экспериментальный (и неподдерживаемый) формат parentdelta;
    • url: использование переменных среды в настройках в секции аутентификации;
    • url: проверка правильности (notBefore/notAfter) с помощью OpenSSL;
  • Команды:
    • addremove: значение 100 используется по умолчанию для опции «similarity»;
    • alias: алиас может начинаться с «!»;
    • backout: использование аргумента --tool для указания внешней программы слияния;
    • dispatch: правильная обработка алиасов относительных путей с использованием -R;
    • log: --follow больше не следует за новым файлом с таким же именем после того, как начальный был удален;
    • merge: обновление до старой ревизии больше не приводит к исключению, если файлы нужной ревизии уже есть в рабочем каталоге;
    • tags: работа с репозиторием больше не заканчивается исключением, если файл tags.cache поврежден;
    • templater: добавлен фильтр «hex» и ключевое слово «children» (смотрите «hg help templating»)
  • Субрепозитории:
    • поддержка переназначения (remapping) начального пути для субрепозитория;
    • команды add, diff, incoming, outgoing и status могут работать также с субрепозиториями при использовании опции --subrepos/-S;
    • поддержка «hg archive» для субрепозиториев;
    • исправлена проверка статуса для субрепозиториев SVN.
  • Revsets. Исправлено несколько мелких ошибок.
  • hgweb:
    • возможность работы HTTPS в режиме большей совместимости при меньшей безопасности;
    • поддержка простой модели кеширования.
  • Расширения. Многочисленные изменения для следующих расширений: color, convert, graphlog, keyword, mq, pager, patchbomb, progress, rebase, strip.
  • Contrib:
    • добавлена поддержка vimdiff для mergetools.hgrc;
    • добавлена поддержка bookmarks- и patchbomb-расширений, а также опции «--move» для команды qpush при использовании автодополнения в zsh.
  • Windows:
    • добавлен установщик для платформы x86_64;
    • правильная обработка пути установки Python, если он содержит пробелы.

Анонс | Список изменений | Cкачать

Также обновился графический клиент TortoiseHg для работы с mercurial до версии 1.1.5.

Анонс | Список изменений | Cкачать

★★★★★

Проверено: post-factum ()
Последнее исправление: CYB3R (всего исправлений: 6)

Ответ на: комментарий от aist1

> Но интуиция мне подсказывает, что можно отгрести неожиданностей, если попытаться смержить два репозитария Hg, один из которых является множеством хардлинков на другой.

Практика подсказывает, что всё нормально. И кстати, репозиторий смерженной ветки можно просто прибить.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Практика подсказывает, что всё нормально.

Я бы всё-таки не решился на такой хак в продакшне. Но в целом, идея интересная, пусть и рискованная. Благодарю за ликбез :)

aist1 ★★★
()
Ответ на: комментарий от aist1

Очевидно, что после мержа двух веток, они станут одной веткой. Если это хранить в одном репозитории, то они так и останутся двумя ветками и это как раз внесет путаницу.

Reset ★★★★★
()
Ответ на: комментарий от Reset

Иными словами, отдельные репозитарии используются для того, чтобы не засорять основной версиями, которые после их завершения уже не представляют больше интереса, даже исторического?

aist1 ★★★
()
Ответ на: комментарий от Reset

Ветками... Для чего-то ведь они создаются. Эксперимента ради, например. Поменять в интерфейсах что-нибудь. А когда эксперимент закончится, то ветка уже не нужна.

aist1 ★★★
()
Ответ на: комментарий от Pavval

>>> зависит. питон очень медленный, соот-но сабж тоже.

Очень медленный в каких задачах?

с каких это пор питон медленнее баш-скриптов? Ты что-то путаешь.

Все критичное к скорости написано на С, потому обертки на баше не влияют.

Разве в Питоне всё на Бэйсике написано?

pythonist
()
Ответ на: комментарий от pythonist

Там автор имел в виду плагин для Git. Его нет, это верно. А HGE - зачетная вещь. Я из-за него склонился в пользу Mercurial у себя.

aist1 ★★★
()
Ответ на: комментарий от aist1

Ты с DVCS работал вообще? Как минимум у каждого разработчика уже имеется своя ветка. Для экспериментов есть mq. Если лениво его изучать, то да, можно и ветку отдельную поднять. Но нафига это делать где-то кроме своей локальной машины и засорять репозитории других участников проекта?

Reset ★★★★★
()
Ответ на: комментарий от pythonist

>Очень медленный в каких задачах?

Деточка, это ты меня спросил?

Все критичное к скорости написано на С, потому обертки на баше не влияют.


Разве в Питоне всё на Бэйсике написано?


Сломал парсер.

Pavval ★★★★★
()
Ответ на: комментарий от Pavval

> Все критичное к скорости написано на С, потому обертки на баше не влияют.

В меркуриале всё работает довольно шустро, а благодаря хорошей архитектуре очень скоро сделали умную систему передачи трафика, к примеру (тоесть, по хттп идёт максимальное сжатие, локально нифига не сжимается и так далее). Модули питоновские, которым важна скорость и так на сях написаны, так что всё тут ок.

Да и вообще. Есть расширение hg-git, которое позволяет делать

hg clone http://github.../somerepo.git

Жду еще для базара подобное и счастье будет полное)

kost-bebix ★★
()
Ответ на: комментарий от Reset

> Но нафига это делать где-то кроме своей локальной машины и засорять репозитории других участников проекта?

Как бы наверное на тот случай если локальная машина накроется или программист выйдет из строя / команды все наработки остались в основном репозитории.

Korwin ★★★
()
Ответ на: комментарий от Korwin

Это тоже решается без засорения основного репозитория. Если программист уходит, то он подготавливает свой репозиторий к сливанию в основную ветку и соответственно потом всё сливает. А для бекапа на сервере делаются ветки hg/project-vasya hg/project-petia ....

Reset ★★★★★
()
Ответ на: комментарий от anonymous

> Это хуже гита. Гит быстрее

на этом достоинства Git заканчиваются :-) [перед Hg и Bzr]

..никто не спорит что Git хорошая и _БЫСТРАЯ_ система...

но не одной же таки-скоростью живём!! удобство тоже важная вешь.. и расширяемость тоже нужна

(программы на Python — довольно хорошо — позваляют себя расширять)

mkfifo
()
Ответ на: комментарий от Pavval

>> Да ты упоролся. Mercurial тебе cp1251 с потолка взяла, что ли?

Если прогу, например, на С++ собрать без #define UNICODE, то она тоже будет жить с 1251. Только это проблема проги, а не винды


1. где об этом написанно в стандарте C/C++ ?

2. почему если туже самую программу (без #define UNICODE ) — собирать в GNU/Linux — то они таки-оказывается Utf-8 ?

mkfifo
()
Ответ на: комментарий от Pavval

правта Mercurial написан на Python .. а Python уже сам по себе поддерживает Unicode (даже на венде)

...такчто то что Mercurial хранит _текстовую_ информацию (такую как имена файлов) — НЕ в Unicode/Utf8 — это действительно бага именно Mercurial :-)

незнаю даже на что надеялись разработчики %) %) %) ..

вродебы на сайте было написанно что ктото в экспериментальном порядке переписал Mercurial на Python-3 %) %) .. может хоть на Python-3 до разрабов них дойдёт unicode-просветление :-)

mkfifo
()

Погуглил немного. Наверное, вот эта статья снимет большинство поверхностных вопросов относительно того, какие методы бранчевания в Hg существуют и при каких условиях могут применяться.

aist1 ★★★
()
Ответ на: комментарий от mkfifo

>1. где об этом написанно в стандарте C/C++ ?

Это касается WinAPI, а не языка.

2. почему если туже самую программу (без #define UNICODE ) — собирать в GNU/Linux — то они таки-оказывается Utf-8 ?


Потому что в винде не юзают UTF-8. Там или UTF-16 (#define UNICODE, whcar_t и WinAPI) или то, что указано в «региональных настройках» на панели управления. А там у всех указано cp1251.

Pavval ★★★★★
()

В mercurial ветки мощнее

В Mercurial возможности создавать бренчи покруче и мощнее будут, чем в git http://pqr7.wordpress.com

anonymous
()
Ответ на: комментарий от aist1

>> А хранят в сжатом виде файлы, и получается что потоковые алгоритмы это только часть полезных для сжатия алгоритмов. Часть других реализована в git. И тема, побольшому счету еще никем не раскрыта

Тема раскрыта. Кури колмогоровскую сложность. Правда, курить придется долго, но стойкое просветление гарантировано :)

Раньше этого не знал. Но из того что быстро нагуглил, колмогоровская сложность - это постановка темы, но не ее раскрытие. И, честно говоря, совсем из другой оперы. Я имел в виду что есть алгоритмы способствующие сжатию файлов помимо алгоритмов потокового сжатия. И в git эти алгоритмы применили. Почему их не применяют в обычных архиваторах мне непонятно. Очевидно стериотипы мышления разработчиков архиваторов.

x86_64 ★★★
()
Ответ на: комментарий от Pavval

>> 1. где об этом написанно в стандарте C/C++ ?

Это касается WinAPI, а не языка.


хм.. спасиб за пояснение!

тогда да: разработчики win-версий библиотек кросплатформенных программ — действительно могли бы уж начинать понемношку это использовать :-)

mkfifo
()
Ответ на: комментарий от kost-bebix

>> - Коммитить часть изменений файла

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

http://mercurial.selenic.com/wiki/RecordExtension, не это?

bulgakov
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.