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)

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

mercurial уже сто лет как можно нормально использовать, а git только только начали приводить в божеский вид, какие там еще косяки остались никому не известно, поэтому лучше уж mercurial использовать

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

Зайди на соответствующую страницу и выполни рекомендации. У меня пока не deprecated, ибо сто лет уже не обновлялся.

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

>mercurial уже сто лет как можно нормально использовать, а git только только начали приводить в божеский вид, какие там еще косяки остались никому не известно, поэтому лучше уж mercurial использовать

Аргументация, мягко говоря, никакая. «Не юзал, но почему-то думаю, что там где-то могут быть какие-то косяки, потому и не буду юзать.»

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

Пробовал несколько лет назад. По сравнению с mercurial git оказался говном. Пробовать сейчас git смысла не вижу, ибо mercurial устраивает полностью.

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

> Проблему отсутствия поддержики Юникода не решает.

Не путай проблему кодировкок в винде с поддержкой Unicode.

// бля, ненавижу эту новую JS-нутую капчу.

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

Опять аргументация зашкаливает.

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

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

х.з., значит что-то другое включить надо, у меня никаких проблем с юникодом нет, файлы с русскими именами в репозитории есть, в линухе и в винде всё одинаково читается

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

> С git проще. Главный репозитарий на сервере. А у нее и помощников у каждого свои. Изменения на сервер заливаются сразу ветками.

Ну тогда Mercurial. Всё так же, только 1) UI проще и 2) gui-клиенты стабильнее и фичастее.

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

>> Проблему отсутствия поддержики Юникода не решает.

Не путай проблему кодировкок в винде с поддержкой Unicode.


А где в винде проблема кодировок? Там еще с Win2000 или раньше юникод. Проблема не в сортирах.

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

> 1. Чем это лучше git'а?

имхо, архитектурно. Это не кучка баш-скриптов и сишного кода, здесь удобно писать расширения на питоне. В остальном — то же самое.

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

> А где в винде проблема кодировок? Там еще с Win2000 или раньше юникод. Проблема не в сортирах.

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

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

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

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

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

> У гита бранчи лёгкие. Впрочем, hg всё равно крут.

У hg лёгкие бранчи называются hg tag. А вот полноценных бранчей в гите нету (хотя и не знаю чем это плохо)).

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

>А вот полноценных бранчей в гите нету (хотя и не знаю чем это плохо)).

Не понял вброс. А чем существующие неполноценные?

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

>> С git проще. Главный репозитарий на сервере. А у нее и помощников у каждого свои. Изменения на сервер заливаются сразу ветками.

Ну тогда Mercurial. Всё так же, только 1) UI проще и 2) gui-клиенты стабильнее и фичастее.

А вот тут как раз и всплывает, что git с бинарниками работает бытсрее и лучше.

x86_64 ★★★
()

Сам пользуюсь гитом, меркуриал не пробовал. Скажите кто юзал, умеет ли он:

- Коммитить часть изменений файла
- Удалаять «старую» историю - то есть всё, что старее определенного коммита
- Определять, в каких бранчах есть данное изменение (в гите зачастую бывает так, что образуется куча веток, в каждой из которых применен один и тотже комит методом git cherry-pick, что порождает коммиты с разными IDшниками, но одинаковым содержимым)

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

>vv@crusader ~ $ equery f python | grep '\.h'

Я сам тупанул, думал они так модули обозвали :)

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

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

Удалаять «старую» историю - то есть всё, что старее определенного коммита

там нет cherry-pick-a вместо него mq. Соотвествтвенно польза от удаления истории не очевидна. И коммит получается один в одну ветку.

anonymous
()

Я поверхностно знаю как меркуриал, так и гит. У меня такое впечатление сложилось, ИМХО:
гит прежде всего рассчитан на огромные проекты (сравнительно с линух ядром), поэтому он и быстрый (а как иначе?), но и вместе с тем имеет более строгие требования к разработчику (так чтобы не напортачить в репе, потому что выгребать будет очень тяжко).
hg проще и в нем меньше заморочек на всяких тонкостях.
Поэтому как мне кажется гит имеет смысл использовать на здоровенных проектах, а на мелких лучше hg, не?

ПС ИМХО! Я и git, и hg слабо знаю. Но такое впечатление сложилось.

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

> имхо, архитектурно. Это не кучка баш-скриптов и сишного кода, здесь удобно писать расширения на питоне. В остальном — то же самое.

Я, возможно, поспорил бы, еслиб знал внутренности меркуриала. Да, гит - смесь баша и С, но это можно назвать по-другому: он следует той идеологии «лучше делать одну вещь хорошо».

И выгода от этого - такаяже как и от всего unix-вейного - при известном напильник-скиле, гит можно малой кровью переделать в файловое хранилище (без истории) или просто в хранилище бинарных данных. Низкоуровневые тулзы это позволяют.

Большинству пользователей оно не нужно, но те, кому выпадет организовывать что-то нестандартное, должны оценить по достоинству.

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

> > Определять, в каких бранчах есть данное изменение

> Удалаять «старую» историю - то есть всё, что старее определенного коммита
там нет cherry-pick-a вместо него mq. Соотвествтвенно польза от удаления истории не очевидна. И коммит получается один в одну ветку.

Пользу от удаления истории могут ощутить любители держать в репозитории бинарники. Особенно, если проекту становится года 2-3. В гите, когда я последний раз интересовался, такая возможность была, но не без ахтунгов - при каких-то условиях что-то могла разладиться при синхронизации с вненими репозиториями.

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

+1. Большие проблемы при подключении, например, к редмайну. Ибо hg log --debug на стометровых(!) исходниках выполняется ..надцать минут и с загрузкой процессора на 100% этим-вашим-питоном.

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

«файлики выбирать», тьфу.

А чо? ^_^ Даже Столлман хочет чтобы СПО юзали ПРОСТЫЕ пользователи, такие как я, а не бородатые админы в свитерах с банками от пива на столе :) Вопросы?

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от FeyFre

>Postgre и тот на git перевели

И кому это чести сделало? Первое - откровенное говно,...

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

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

>> имхо, архитектурно. Это не кучка баш-скриптов и сишного кода, здесь удобно писать расширения на питоне. В остальном — то же самое.

Я, возможно, поспорил бы, еслиб знал внутренности меркуриала. Да, гит - смесь баша и С, но это можно назвать по-другому: он следует той идеологии «лучше делать одну вещь хорошо».

И выгода от этого - такаяже как и от всего unix-вейного - при известном напильник-скиле, гит можно малой кровью переделать в файловое хранилище (без истории) или просто в хранилище бинарных данных. Низкоуровневые тулзы это позволяют.

Большинству пользователей оно не нужно, но те, кому выпадет организовывать что-то нестандартное, должны оценить по достоинству.

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

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

> зависит. питон очень медленный, соот-но сабж тоже.
Специально для тебя в mercurial наиболее критические к скорости места написаны на с.
P.S. Еще Жванецкий предлагал спорить о вкусе устриц с теми кто их ел.

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

> он следует той идеологии «лучше делать одну вещь хорошо»

ну и где же тогда нативная libgit, которая хорошо работает с репозиториями Git? И почему CLI утилки git-* не являются фронтендом к ней?

при известном напильник-скиле, гит можно малой кровью переделать в файловое хранилище (без истории) или просто в хранилище бинарных данных. Низкоуровневые тулзы это позволяют.

Понятно. Троллейбус из буханки хлеба.

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

> аналог для staging area - mq.

совсем замечательно

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

> Называть Postgre откровенным говном - это сильно. Очевидно вы страдаете избытком радикализма, что сильно намекает на возраст.

25 лет - мой возраст. Могу паспорт показать. У Вас какие-то проблемы с возрастом или радикализмом? Или назвать говно говном для Вас считается чем-то из ряда вон выходящим?

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

> Ты забыл вылогиниться, прежде чем писать настолько толстые вещи. Теперь придется тебе ник менять, иначе твое мнение на лоре по любому вопросу будет весомым только среди таких же альтернативно развитых.

Где тут говорите настройка игнорировать анонюг?

Я на ЛОР не полемикой заниматься прихожу, а за технической консультацией. И мне плевать, считают меня тут православным или еретиком. Это только Вы между перекурами языком тут чешете.

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

Где встречал такую фразу «mercurial подглядывает у git функциональность, а git у mercurial юзабельность»

это с быдлохабра

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

> <вброс>В то время, как гит идеален и к нему не надо писать расширения</вброс>

негодный)

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

Ветка, естественно, одна. Вообще мне не понятен смысл держать несколько веток в одном репозитории для DVCS. Коммитов 218. Мерджей? А как их посчитать оно же в истории обычным коммитом отображается.

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

Ну. текущие — это «лёгкие бранчи». Тоесть к ченджсету крепится ярлык с именем бранча, и когда что-то коммитится как родитель этого ченджсета — ярлык этот перемещается. (в меркуриале это расширение hg bookmarks)

В случае же с полноценными бранчами — информация о ветке хранится в каждом ченджсете и может бродить между репозиториями.

Хорошое описание разных моделей веток здесь http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/

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

> Ветка, естественно, одна. Вообще мне не понятен смысл держать несколько веток в одном репозитории для DVCS. Коммитов 218. Мерджей? А как их посчитать оно же в истории обычным коммитом отображается.

Когда веток много - удобно следить после каких изменений она родилась. Графическое представление позволяет на взгляд определить ветки в которых присутствует одна и та же ошибка, а в каких ее нет.

Ну а множество веток - удобное поле для экспериментов.

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

>> Называть Postgre откровенным говном - это сильно. Очевидно вы страдаете избытком радикализма, что сильно намекает на возраст.

25 лет - мой возраст. Могу паспорт показать. У Вас какие-то проблемы с возрастом или радикализмом? Или назвать говно говном для Вас считается чем-то из ряда вон выходящим?

К возрасту претензий ни укого нет. Обычно есть претензии к незрелым суждениям, соответствующим малому возрасту. Радикализм говорит о незрелости суждений. Если радикализм сопутствует возрасту зрелых суждений, то дела, обычно, совсем плохи.

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