LINUX.ORG.RU

Hg/Mercurial 3.4

 


0

5

Вышла очередная версия свободной распределённой системы управления версиями (DVCS) Mercurial, использующейся при разработке таких крупных проектов, как Python, Firefox, Nginx и OpenSolaris. Основные нововведения этой версии:

  • Переход по умолчанию на протокол bundle2, который, по словам разработчиков, значительно повышает скорость выполнения команд pull и push в сравнении со старым протоколом, bundle.
  • Значительные улучшения производительности: так, например, скорость работы команды hg diff была увеличена на 20%, hg status — на 25% (не на всех платформах), а hg revert в некоторых случаях стала выполняться быстрее почти в 4 раза.
  • В веб-интерфейсе hgweb, была добавлена возможность отдачи результатов вызова к API в формате JSON.
  • Добавлена (пока ещё экспериментально) команда hg censor, позволяющая навсегда запретить клонирование из репозитория определённой информации.
  • Добавлена возможность произвести сравнение репозиториев командой hg diff --root относительно определённой директории (по словам разработчиков, это полезно при, например, добавлении патчей к чужим проектам в своём репозитории).
  • Добавлена экспериментальная поддержка нового бэкенда для манифестов, позволяющая, например, клонировать только определённые директории из репозитория.

>>> Подробности



Проверено: leave ()
Последнее исправление: CYB3R (всего исправлений: 4)

Переход по умолчанию на протокол bundle2, который, по словам разработчиков, значительно повышает скорость выполнения команд pull и push в сравнении со старым протоколом, bundle.

А на опеннете написано, что это только на сервере, а на клиенте его всё ещё надо включать вручную.

vurdalak ★★★★★
()

OpenSolaris

Illumos действительно использует Mercurial, но всё-таки.

Darth_Revan ★★★★★
()

Самая удобная DVCS. Пробовал и git и другие (fossil). Для своих проектов использую только его (очень редко git). Простота использования и почти официальный GUI (TortoiseHg) и всегда свежая версия под все платформы это то, чего мне не хватает в git. Есть конечно свои минусы (например работа с файлами на кириллице), но они все незначительны.

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

Там есть одна беда с кодировками между платформами. Тоесть если сохранить файл с русским названием на Windows например, то на других платформах Mac/Linux он будет очень криво отображен (кракозябры). Но это касается только имени файла.

RevenantX ★★★★
()
Последнее исправление: RevenantX (всего исправлений: 1)
Ответ на: комментарий от BattleCoder

А ну если так, значит вообще не вижу причин использовать git) Мне нравится концепция сохранения полной истории у меркуриала в целом (никаких ребейсов и красивые graft (cherry-pick))

RevenantX ★★★★
()

Мдя, а тут у меня

$ hg --version
Mercurial Distributed SCM (version 1.4)

Copyright (C) 2005-2009 Matt Mackall <mpm@selenic.com> and others

AlexVR ★★★★★
()

верни свою старую аватарку

Harald ★★★★★
()
hg --version
Распределенная SCM Mercurial (версия 2.8.2)

Ничего себе у меня такая старая...

Радость! Наверное надо переползать.

I-Love-Microsoft ★★★★★
()

Ну и хорошо. А насколько нужно — не мне судить.

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

Очень не скоро

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

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

Пока python2 будет официально поддерживаться, они не будут с него слезать. На самом деле это не проблема) Хотя конечно хочется, чтоб они таки начали этот процесс потихоньку.

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

У них там куча лишнего (баг трекер, который я не нашел как отключить). Да и в целом встроенный веб сервер ужасный.

RevenantX ★★★★
()

hg censor

«При финансовой поддержке Федеральной службы по надзору в сфере связи, информационных технологий и массовых коммуникаций»?

И почему еще нет срача Git/Hg/Bazaar/SVN?

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

В Python 3.5 только появится PEP 0461, который необходим для перехода.

Есть вариант hglib, там с поддержкой python3 намного проще.

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

В Python 3.5 только появится PEP 0461, который необходим для перехода.

Нафига им форматировать байтовые строки? Не проще в юникод их переводить?

vurdalak ★★★★★
()

Надо было скопировать с опеннета пункт про интерактивный режим: теперь commit, revert и shelve умеют --interactive, чтобы выбирать отдельные чанки (похоже на git add --patch). Плюс на опеннете упомянута настройка experimental.crecord=true, чтобы этот интерактивный режим использовал curses (на оффтопике вроде не работает).

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

Нафига им форматировать байтовые строки?

wire protocol

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

И почему еще нет срача Git/Hg/Bazaar/SVN?

Потому что уже нет повода для срача.

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

Перекатываться смысла нет. Что тебе попалось первоначально, то и используй. Разница в основном только в наборе команд и подходе к сохранности истории.

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

Не сможешь использовать GitHub.

Какому нормальному человеку придет в голову использовать его? Проприетарное поделие без приватных репов с кривым интерфейсом.

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

Опа, офигеть!!! Надо-таки как-нибудь попробовать по-нормальному научиться hg... а то всё git, да git.

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

Второе звучит очень интересно, а вот по первому пункту можно не очень абстрактный пример из повседневной работы?

Ещё, кстати, я на аналог quilt завидовал там, по-моему patch queue называется, ты его не упомянул?

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

по первому пункту можно не очень абстрактный пример из повседневной работы?

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

Ещё, кстати, я на аналог quilt завидовал там, по-моему patch queue называется, ты его не упомянул?

Он называется Mercurial Queues (mq), но в git есть аналоги.

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от anonymous

И ещё это, раз уж revsets упомянуты.

Ну да, просто я сам никогда этим не пользовался.

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

Он называется Mercurial Queues, но в git есть аналоги.

Интересно-интересно, это ты не на интерактивный ребейз намекаешь? Если да, то что меня в нем расстраивает, так это то, что неудобно в сторону патчи откладывать. Всё, разумеется, можно сделать, но mq приятнее. Если нет, хотелось бы узнать, что за аналоги такие, буду пользоваться тогда.

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

это ты не на интерактивный ребейз намекаешь

Нет. quilt настолько удачная вещь, что ее реализовали и для git - stgit и еще что-то, что я не помню. И один вынужденный переселенец из Mercurial реализовал guilt.

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

stgit выглядит круто, только что-то его страничка не открывается, а вот guilt как-то неприятно. Спасибо большое, попробуем первый вариант...

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

второе и часть первого есть в гите

У тебя, похоже, свой git с бдж и ш.

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

hg-git же ну

Хватает для одноразового доступа. Я так и не смог его заставить коммитить на git-сервер изменения, чтобы они через какое-то время не начинали вызывать конфликты на git-стороны (при чём кроме hg-git с той стороной никто не работал).

В итоге стал использовать связку fast-export (конверсия hg в git) и уже из полученного git — push в репу. Тогда, более-менее, всё работает как ожидается. Т.е. можно наработки из hg пихать в git. Правда, нельзя наоборот :)

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

Это и это

Прикольно. Правда, второе при наличии любой мало-мальски продвинутой системы коде-ревью поверх vcs - уже не так «инновационно». Ну, в смысле, «мы и так это умеем», правда, немножко другими средствами.

А первое... Тебе часто пригождаются сложные варианты выборок, за пределами того, что умеет git log & co?

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

второе при наличии любой мало-мальски продвинутой системы коде-ревью поверх vcs - уже не так «инновационно»

Любой? ReviewBoard? Gitlab, Gitorious? Да и к review это имеет довольно косвенное отношения.

Ну, в смысле, «мы и так это умеем», правда, немножко другими средствами.

Ну, «немножко другими средствами» это умеют даже патчи.

А первое... Тебе часто пригождаются сложные варианты выборок, за пределами того, что умеет git log & co?

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

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

Да и к review это имеет довольно косвенное отношения.
Ну, «немножко другими средствами» это умеют даже патчи.

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

Соответственно, выбор инструментария так или иначе крутится вокруг систем code review. Вообще, я уже лет 10 как сижу на различных CRS и прочей непрерывной интеграции, поэтому для меня это уже неотъемлемая часть. Ну, точнее, как «неотъемлемая». Как бампер или ремни безопасности. Ездить, конечно, можно и без бампера, и отдельные таланты считают, что так и дóлжно. Но мы-то знаем, что они неправы? :)

Gitlab, Gitorious

Gitorious всё, часть gitlab-а. А так, и gitlab, и github имеют вменяемую систему для работы с пул-реквестами. gerrit'овая, конечно, нравится мне больше, но я просто старый пердун.

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

Да и к review это имеет довольно косвенное отношения.
Ну, «немножко другими средствами» это умеют даже патчи.

Нет.

Да (хотя я и не понял, к чему относилось твое «нет»).

Gitorious всё, часть gitlab-а

Не видел такого в Gitorious, но спорить не стану. Линк на описание процесса есть?

вменяемую систему для работы с пул-реквестами

Тоже косвенное отношение. Хотя, конечно, «вменяемая работа с пулл-реквестами» достаточно широкий термин.

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

Да (хотя я и не понял, к чему относилось твое «нет»).

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

Линк на описание процесса есть?

Есть конечно. Для gitlib'а процесс описан здесь, а здесь описано API. Аналогичные документы есть для pull request'ов в github'е. Для gerrit'а неплохой туториал с картинками есть у Медиавики.

Вообще, конечно, из этих трёх gerrit, похоже, самый продвинутый. Там есть хорошая автоматизация (интеграция с CI итп), несколько типов патчсетов (например, драфты, которые предназначены исключительно для «выставить на поругание обозрение», и не могут быть засабмиттаны без перевода из статуса draft в обычный, ну и разные другие фишки-плюшки. Плюс достаточно легко пишутся кастомные расширения.

Тоже косвенное отношение

Хорошо, какие ещё применения, помимо code-review и тому подобного, есть у отслеживания изменений в изменениях?

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