Здравствуйте, alex_public, Вы писали:

_>>>Ну так это только в git надо корёжится (не допускать gc, непонятным образом искать id и т.п.), а в mercurial это всё идеально удобно.
N>>Если хочешь дальше общаться, прекращай это НЛП в виде регулярной мантры "идеально удобно", или я просто прекращу обсуждение и буду считать тебе техническое поражение. Надоело. Или мы говорим проверяемыми аргументами без вкусовщины (во что входит соответствие общепринятым терминам и распространённым практикам), или мне такое не подходит.
_>Вообще то как раз только что я и сделал попытку количественного анализа данного субъективного вопроса — предложил сравнить необходимые команды в разных системах для реализации одной и той же задачи. Однако ты её проигнорировал, без внятного объяснения.

Что ты называешь этой задачей? Проведение развития пучка веток без явной маркировки голов названиями веток? Я объяснил уже, почему считаю это не просто бесполезным, но и вредным. Поэтому решение этой задачи я в принципе не рассматриваю.

А вот та задача, на которую должна быть оптимизирована любая DVCS, в основе формулируется следующим образом. Имея некоторый проект (неважно, public/private, opensource/закрытый), выполнить задачу (добавить фичу, полечить баг, whatever), для чего
а) сделать копию репо, если ещё нет
б) отделить в явном виде конкретную работу (что означает её таки назвать, потому что при >=2 таких начинаешь путаться, что где делаешь, а от 4 средний программист совсем потеряет понимание)
в) в процессе работы, войдя в контекст, генерировать последовательность коммитов для её решения (причём, если это совместная работа, каждый коммит сам по себе должен быть, как класс в SOLID, прост, понятен и решает ровно одну цель)
в2) при необходимости, порождать подзадачи и вести их решение отдельно, потом возвращаясь вверх;
г) иметь удобную (что бы это ни значило) возможность в процессе объединения решения с другими производить адаптации уже сделанного
д) в процессе code review иметь возможность обрабатывать замечания, причём к не-последним коммитам
е) иметь удобную (опять же, не уточняем пока детали) возможность иметь локальные изменения, которые остаются только локальными
ж) в следствие экспорта изменений другим, они не должны выглядеть для них принципиально "чужеродными", приходить предельно лёгким путём (любым из) и естественно ложиться в локальные репозитории

А теперь смотрим на Hg, имея в виду сравнение одновременно с CVCS (CVS, SVN) и Git (согласно моему опыту работы больше, чем на сделать пару мелких тестов):
(а) — проблем нет; для CVS, SVN меняется на checkout рабочей копии без репо;
(б) — для DVCS, требует какого-то вида бранчевания (если не решается в один чих), но именованного под растущую ветку => для Hg это bookmarks; для CVCS — всё в рабочей копии, если нет центрального решения выделить под это ветку;
(в) — не проблема, если реализация изначально идеальна для момента коммита; если нет, упираемся в проблемы (г) и (д);
(в2) — решается в любой DVCS суббранчеванием, в CVCS клонированием рабочих копий;
(г),(д) — требует interactive rebase; считаем, работает только в Git;
(е) — требует stash и interactive-add (patch-add как вариант), или даже edit-add; везде, кроме Git, приходилось временно делать копию рабочих файлов, вырезать не запланированное на данный коммит, и потом возвращать;
(ж) — "дискардит" смысл в Hg'шных номерах коммитов в цепочке (как 0: в 0:32f5bb09 и тому подобных знаках), между репо работают только хэши как идентификаторы; в CVS и SVN работает, пока нет конфликтов; конфликты в SVN решаются легче, чем в CVS, но всё равно хуже, чем в Git; про качество решения конфликтов в Hg не в курсе.

Для меня самым ограничительным в плане выбора средств оказывается (е) — и он привязывает только к Git. Причём, были ситуации, что у конторы центральным средством был CVS, но локальное удобство заставляло использовать Git; даже лёгкий гимор на операции "после cvs update пришли обновления, их надо влить локально" оказывался терпимым. Также для того, чтобы было не стыдно смотреть на результат, почти всегда нужен (г).
Часть пунктов не ограничивает, но приводит к тому, что в Hg заморочка локальными фичами типа номеров ревизий (ж) и безымянными головами (б) тратит мозговые ресурсы.

_>Я понял твои мысли там. Но непонятно какое они имеют отношение к вопросу сравнения числа команд для решения конкретной задачки. У тебя какие-то претензии к такому подходу? )

Да. Я считаю бессмысленным сравнивать количество команд, пока не выровнены сами задачи и под идентичную формулировку для сравниваемых средств, и под собственно осмысленность и важность задач. После того, как мы приводим понятие ветки в адекват с общим пониманием и с необходимостью не иметь всякие безымянные головы, со стороны Hg остаются bookmarks и разница исчезает.

_>>>Ну а насчёт удобства... Про принцип Оккама не забываем! )
N>>И что он тут даёт в твою пользу? В мою вижу — появилась излишняя сущность "безымянные цепочки" с диверсионными последствиями.
_>Как раз придумывание имени ветки, которая существует например только ради синхронизации — это и есть очевидно лишнее.

Если "синхронизацией" называется слияние с верхним репо — то или эта ветка как образец того, что зафиксировалось в верхнем репо, должна существовать всегда, или она не нужна — pull делает merge, pull+rebase делает rebase.
Если общая схема с изменениями от кого-то другого, то представь себе ситуацию, что он что-то меняет от точки истории, которая на 200 коммитов назад — ты в любом интерфейсе вначале будешь долго мотать, чтобы её найти, или он будет показывать растянутые линии. А если таких несколько, то уже начнётся постоянная путаница, где чьи изменения и что из них надо принимать. Идею оптимизации на набор двух символов я понимаю, но принять её как-то сложно.
Про security issues такой фичи я уже упоминал.