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)

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

> Отдельная ветка — отдельный репозиторий. Так гораздо проще разбираться в коде.

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

Мне вон вообще подавай и ветки и проекта и ветки подпроекта в одном репозитории. Причем ветки подпроекта полностью выглядят как отдельный проект.

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

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

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

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

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

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

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


нет, удалять историю не умеет, но вроде как можно заэкспортировать в новый «чистый» репозиторий нужную тебе ревизию

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


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

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

впечатление ложное сложилось. Меркуриал (как и гит) прекрасно использовать на огромных проектах

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

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

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

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

Я на ЛОР не полемикой заниматься прихожу, а за технической консультацией.

на ЛОР не полемикой ..., а за технической консультацией

на ЛОР ... за технической консультацией

на ЛОР ... за технической консультацией

на ЛОР ... за технической консультацией


Ты сделал мой день.
А на фороникс за аналитическими статьями ты случаем не ходишь?

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

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

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

Просто чтобы ты знал - сабж временами обгонял git. Так что про медленность лучше бы ты промолчал...

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

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

А зачем тебе --debug?

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

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

Вроде оно: http://mercurial.selenic.com/wiki/RecordExtension, но я не пользовался таким.

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

Изменять историю, которой уже поделился с другим репозиторем, в hg вообще нельзя. Нельзя сделать так, чтобы при pull у меня что-то пропало из истории.

Можно сконвертировать репозиторий в новый независимый, при этом ограничить глубину истории. Но это будет никак не связанный репозиторий, нельзя будет делать pull/push с исходным.

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

В hg есть аналогичное действие: http://mercurial.selenic.com/wiki/TransplantExtension Но специальной информации по таким changesets вроде не ведется, хотя для локального репозитория вроде что-то есть: «Transplanted patches are recorded in a .hg/transplant/transplants file, as a map from a changeset hash to its hash in the source repository.»

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

> Нет. Коммитить умеет только ченджсеты (наборы изменений).

record extension

нет, удалять историю не умеет

histedit extension

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

> git с бинарниками работает бытсрее и лучше.

И чем же лучше? Кроме переименования.

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

Это я к примеру, что редмайн так оттуда дёргает историю правок. Можно, конечно долго говорить что Жан-Филипп чудак и делает это через задницу, но разница по времени между выпиской дефолтной и с --debug чудовищна:

time hg log > /dev/null hg log > /dev/null 3,71s user 0,05s system 90% cpu 4,168 total

И такое поведение сохраняется на последней транковой версии меркуриала и третьем питоне.

Ну, и вообще, мало ли мест, где мне может потребоваться развернутая выписка? Я отнюдь не говорю, что «меркьюрикал нинужен» и всё такое, сам пользуюсь как гитом, так и хг. Но просто вот у меркуриала нашел такой вот bottleneck, чем сильно опечален.

Я примерно догадываюсь в чем может быть причина засора, может есть какой hg defrag или hg gc? ..

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

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

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

>Зачем ветки хранить внутри я тоже не понимаю.

Если это центральная репа чего-то сложнее «hello world» и двух разработчиков. Да, бывают и такие проекты ;)

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

> Можно, конечно долго говорить что Жан-Филипп чудак

Похоже на то.

Ну, и вообще, мало ли мест, где мне может потребоваться развернутая выписка?

Я поэтому и спросил - зачем тебе --debug. Я вот за 5+ лет работы с Mercurial ее ни разу не использовал (максимум, что нужно было - свой шаблон подставить).

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

Если это «центральная репа чего-то сложнее „hello world“ и двух разработчиков.» то, наоборот, сам бог велел для каждого разработчика организовать отдельную ветку в отдельном репозитории, а не городить непонятную кашу в одном месте.

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

>Я поэтому и спросил - зачем тебе --debug

«Если есть световая скорость, надо её включить» к/ф Космобольцы

Кто-то пользуется годами меркуриалами, гитами и ни разу не использовал bisect, rerere или что-то подобное. Но это совсем не означает, что эти функции должны тормозить или работать некорректно.

Тот же самый репозиторий, сконверченный в git с сохранением всех мержей/комитов выплёвывает логи мгновенно.

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

>для каждого разработчика организовать отдельную ветку в отдельном репозитории

угу. А теперь нас секунду представим, что разработчиков больше 200. При этом веток сейчас всего 37.

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

Не вижу проблем. Пусть ветки у себя на локальных машинах держат. Нафига весь шлак в центральный репозиторий тащить и создавать там непонятную кашу?

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

200 веток в одном репозитории это мягко говоря 3.1415здец. И майнтейнера, который довел проект до такого состояния надо гнать сцаными тряпками, покуда он чего хуже не вытворил, хотя куда уж хуже ...

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

А теперь ещё раз перечитай моё сообщение. Где там написано что на каждого разраба по ветке?

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

> Тот же самый репозиторий, сконверченный в git с сохранением всех мержей/комитов выплёвывает логи мгновенно.

А у git есть опция --debug?

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

Есть --verbose, но не для логов. Для логов куча всяких опций, в том числе построение ASCII-графиков и пр.

Понимаю, к чему клонишь: мол, от слова debug не надо ожидать какой-то особой прыти. Но ведь в других продуктах это не сильно сказывается на производительности.. взять тот же nginx или postgres. Я бы на месте селеника переименовал её в --full-and-slow :-)

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

>Можно, конечно долго говорить что Жан-Филипп чудак и делает это через задницу

Так оно и есть

Ну, и вообще, мало ли мест, где мне может потребоваться развернутая выписка?

Для развёрнутой выписки есть --verbose

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

В общем, вся эта брехня mercurial vs. others бесполезна.. я просто надеялся что в этой версии пофиксят то, что нужно 0.0001% пользователей, но нет. Собственно и всё.

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

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

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


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

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

> Для логов куча всяких опций, в том числе построение ASCII-графиков и пр.

То есть ты понимаешь, что сравнение с git некорректно. Кстати, в mercurial тоже есть ASCII-графики :)

Понимаю, к чему клонишь: мол, от слова debug не надо ожидать какой-то особой прыти. Но ведь в других продуктах это не сильно сказывается на производительности..

Откуда ты знаешь, что в других продуктах под капотом?

я просто надеялся что в этой версии пофиксят то, что нужно 0.0001%

Хотя я пользуюсь hg постоянно, у меня только одна серьезная претензия - переименование корявое.

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

>То есть ты понимаешь, что сравнение с git некорректно.

Ну а с чем ещё сравнивать? самый ближайший из похожих продуктов..

Откуда ты знаешь, что в других продуктах под капотом?

Точно знаю, что в озвученных мною не питон :)

Хотя я пользуюсь hg постоянно, у меня только одна серьезная претензия

Хотя я пользуюсь hg постоянно, у меня только одна серьёзная претензия - тормоза при hg log --debug и одна несерьёзная - плагины.

Складывается впечатление что git - opera (максимум изкоробки, даже то, чего не заказывал), hg - firefox (базовый функционал, остальное в плагинах).

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

> Хотя я пользуюсь hg постоянно, у меня только одна серьёзная претензия - тормоза при hg log --debug

Колись, что тебе (как живому человеку, а не программе) нужно в log --debug? Я любопытства ради прогнал его - ничего особо полезного не вижу.

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

Мне надо чтобы редмайн не вешал сервак если кто-то тыкает на кнопочку «Хранилище». К сожалению, времени на ковырянии в рельсах и отлов того зачем/почему/какого лешего оно спаунится с дебагом и что из него оно сосёт, у меня нет.. поэтому жду решения с двух сторон: либо (д)одумаются японские редмайновцы (https://github.com/marutosi/redmine-mercurial) либо селеник ускорится.

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

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

В моё селе востребован Оракл, Мускул, Информикс, оффтопный JET/MS Access. А если в Вашем селе не из чего выбирать, то да, он для Вас более развит и более востребован.

Разработчики Postgre тоже могут читать ЛОР, и такие заявления будут как минимум неуважением к их труду.

Значит на Мускул/Оракл/Jet/SQLite/MSSQL можно наезжать, а на Постгре нельзя? Повторю, от того что говно перестанут называть говном, оно говном не перестанет быть. А вот если почаще называть, авось разработчики что-то допилят и степень говняности уменьшится.

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

Чего-то у вас одни сопли. MySQL vs Postgee vs SQLite :-D Спасибо, посмеялся.

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

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

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

Один советует завести овер 200 репозиториев, другой - прописать в каждом необходимые плагины... Кстати, эти плагины ещё надо найти и поставить. Спасибо, не надо..

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

[quote] вообще не аргумент. [/quote]

Хостинг? Сколько будет стоить такая «веточка» для репозитария размером 100М?

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

> Хостинг?

А что «хостинг»? На своем сервер не судьба репозиторий хранить?

Сколько будет стоить такая «веточка» для репозитария размером 100М?

Нисколько. man hardlinks.

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

Для проекта из 37 веток и 300 метров исходников можно и приличный купить. Хотя в данном конкретном случае речи о хостинге скорее всего не идет.

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

А что «хостинг»? На своем сервер не судьба репозиторий хранить?

Это вопрос экономический. Свой домашний сервер либо хорошо электричество кушает, либо если дедик - тоже денег хороших стоит.

Нисколько. man hardlinks.

Да, можно. Но мне кажется, это уже несколько выходит за пределы обсуждения сабжа и его альтернатив. Их назначение - сделать жизнь проще, а не наоборот.

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

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

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

Я даже заинтригован такой безаппеляционностью.
Чем плох Postgre то? Мне правда интересно.

Мускул/Оракл/Jet/SQLite/MSSQL

Плотно работал со всеми из них, кроме Jet (вообще не знаю что это).

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

> Свой домашний сервер либо хорошо электричество кушает, либо если дедик

Херасе альтернатива. Обычно в команде, разрабатывающей софт, есть дохрена всяких машин. Вот и размести на одной из них репозиторий.

Нисколько. man hardlinks.

Да, можно.

Никаких «да, можно» - просто «да».

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

И каким образом прозрачное использование нардлинков «под капотом» этому мешпют?

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

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

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

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

И каким образом прозрачное использование нардлинков «под капотом» этому мешпют?

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

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