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

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

OpenSolaris

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

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

А что у него с файлами на кириллице?

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

В git та же беда. Было бы плюсом, если бы порешали. ;)

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

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

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

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

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

А не знаете, когда они планируют слезать с python2?

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

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

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

fossil же проще некуда.

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

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

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

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

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

hg censor

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

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

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

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

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

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

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

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

wire protocol

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

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

Юзаю гит во все поля. Что я выиграю, если перекачусь на это поделие?

репы на гитхабе

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

Что я выиграю, если перекачусь на это поделие?

Это и это, а еще нормальный UI. Впрочем, если ты уже привык к Git, последний пункт не для тебя.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

второе и часть первого есть в гите. у меня нормальный UI, называется magit.

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

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

hg-git же ну

GitUM?

ещё полезная документация искаропки

Жесть. А чем SourceTree не устроил?

мод для емакса есть?

hg-git же ну

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

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

Зачет! Расширение crecord отключаю!

Это и это

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

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

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

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

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

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

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

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

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

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

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

Gitlab, Gitorious

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

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

Нет.

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

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

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

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

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

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

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

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

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

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

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

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