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

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

Ну и зря. Если лично тебе оно не нужно, то это не значит что и другим тоже. Я знаю многих использующих Mercurial вообще без named branches/bookmarks и при этом очень довольных удобством работы.

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

В принципе логично написано.

N>А теперь смотрим на Hg, имея в виду сравнение одновременно с CVCS (CVS, SVN) и Git (согласно моему опыту работы больше, чем на сделать пару мелких тестов):

Ох, ну я же ещё в самом начале этой дискуссии писал, что за годы параллельного развития все современные dcvs обрели приблизительно одинаковые технические возможности (ну вот разве что git так и не научился по нормальному анонимным веткам) и выбор должен делаться только по удобству (достаточно субъективная вещь) их использования. Ну если хочешь, можем разобрать по пунктам. )

N>(а) — проблем нет; для CVS, SVN меняется на checkout рабочей копии без репо;
N>(б) — для DVCS, требует какого-то вида бранчевания (если не решается в один чих), но именованного под растущую ветку => для Hg это bookmarks; для CVCS — всё в рабочей копии, если нет центрального решения выделить под это ветку;

Для hg это или bookmarks или named branch, в зависимости от предпочтений в поведение.

N>(в) — не проблема, если реализация изначально идеальна для момента коммита; если нет, упираемся в проблемы (г) и (д);
N>(в2) — решается в любой DVCS суббранчеванием, в CVCS клонированием рабочих копий;
N>(г),(д) — требует interactive rebase; считаем, работает только в Git;

В Mercurial это тоже реализовано, через команду hg histedit. Однако я крайне не рекомендую использовать этот подход, т.к. правильным методом review в DCVS должно быть создание новой ревизии.

N>(е) — требует stash и interactive-add (patch-add как вариант), или даже edit-add; везде, кроме Git, приходилось временно делать копию рабочих файлов, вырезать не запланированное на данный коммит, и потом возвращать;

В Mercurial соответственно hg shelve и hg record ("hg commit -i" начиная с версии 3.4). Лично я возможность "hg commit -i" никогда не использую, но если кому-то надо, то оно имеется...

N>(ж) — "дискардит" смысл в Hg'шных номерах коммитов в цепочке (как 0: в 0:32f5bb09 и тому подобных знаках), между репо работают только хэши как идентификаторы; в CVS и SVN работает, пока нет конфликтов; конфликты в SVN решаются легче, чем в CVS, но всё равно хуже, чем в Git; про качество решения конфликтов в Hg не в курсе.

Кстати, решение конфликтов — это должен был бы быть ещё отдельный пункт (ж — это же у тебя про экспорт/импорт). Но думаю там особых отличий нет, хотя алгоритмы и совсем разные. А вот что касается экспорт/импорта, то как раз тут у Mercurial всё намного проще и удобнее. Тут и наличие анонимных веток и их поведение при синхронизации (они просто все возникают у всех) и ещё много мелких нюансов. Т.е. те же цели достигаются тут гораздо меньшими усилиями.

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

Ну как видишь никаких ограничений нет на самом деле (и я кстати об этом говорил изначально). Есть только разница в удобстве (причём в пользу Mercurial). Люди даже подобные https://www.mercurial-scm.org/wiki/GitConcepts#Command_equivalence_table таблички соответствия команд делают. ))) Но опять же там есть не все команды (например нет heads) из-за отсутствия в конкуренте соответствующей концепции (типа анонимных веток).

N>Часть пунктов не ограничивает, но приводит к тому, что в Hg заморочка локальными фичами типа номеров ревизий (ж) и безымянными головами (б) тратит мозговые ресурсы.

Это от непривычки. ) А потом оказывается, что это ещё и намного удобнее старых подходов.

_>>Как раз придумывание имени ветки, которая существует например только ради синхронизации — это и есть очевидно лишнее.
N>Если общая схема с изменениями от кого-то другого, то представь себе ситуацию, что он что-то меняет от точки истории, которая на 200 коммитов назад — ты в любом интерфейсе вначале будешь долго мотать, чтобы её найти, или он будет показывать растянутые линии. А если таких несколько, то уже начнётся постоянная путаница, где чьи изменения и что из них надо принимать. Идею оптимизации на набор двух символов я понимаю, но принять её как-то сложно.

Я вот здесь http://rsdn.ru/forum/flame.comp/6338865.1

Автор: alex_public
Дата: 06.02.16

приводил картинку того, что имею в виду. Предположим что ревизии 2 и 3 созданы на разных компьютерах. Как бы ты реализовал подобное с помощью git? )