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

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

Трудно читать на украинском) Хотя смысл угадывается конечно. )))

N>...
N>Заметь, человек для себя предпочитает Hg, но его подобные грабли таки достали. Я до такой глубины ещё даже первично не докопался.

Из существенных претензий тут только пункт с close-branch. Если бы он был правдивый (тут уже вроде всё показали на эту тему).

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

Как раз использовали для совместной работы. Правда небольшими командами (в крупных и формализованных командах всё же уже требуются именованные разделители какого-то вида). Очень удобно.

_>>Ох, ну я же ещё в самом начале этой дискуссии писал, что за годы параллельного развития все современные dcvs обрели приблизительно одинаковые технические возможности (ну вот разве что git так и не научился по нормальному анонимным веткам) и выбор должен делаться только по удобству (достаточно субъективная вещь) их использования. Ну если хочешь, можем разобрать по пунктам. )
N>Ну да, теперь осталось сделать совсем немного мелочей:
N>1. Внести такие действительно полезные вещи, как shelve, record, histedit, rebase в базовую функциональность, а не расширения.

А чем по твоему отличаются расширения входящие в поставку Mercurial от обычных команд? ) Лично я не вижу вообще никакой разницы.

N>2. Диверсии в виде неименованных голов, наоборот, вынести в расширения и не включать по умолчанию.

Как ты себе представляешь отключение по умолчанию базовой функциональности, вокруг которой и строится вся система? )))

N>3. Описанным расширениям довести функциональность до минимально необходимого набора:
N>* показ staging, сброс staging в ноль, частичный сброс (по файлу, по диффу).
N>* shelve должен уметь брать не только локальные изменения, но и staging.

Возможно допилят (я же говорю, что технические возможности систем сходятся постепенно). Хотя лично я и все мои окружающие вообще не пользуются командой record, даже в таком виде. Собственно большинство вообще из IDE работает, где это всё неактуально.

N>4. Решить остальные описанные Lyubomyr Shaydariv проблемы. Для начала, переименовать таки "ветки" во что-то другое (покопался в словаре, нашёл замечательное слово tally). Далее, обеспечить возможность их делать неуникальными (а лучше вообще не опираться на "закрытие", эта концепция должна умереть). Решить остальные описанные им проблемы.

Это вроде уже обсудили. )

_>>В Mercurial это тоже реализовано, через команду hg histedit. Однако я крайне не рекомендую использовать этот подход, т.к. правильным методом review в DCVS должно быть создание новой ревизии.
N>Я проверил — histedit меняет хэш ревизии, так что тут, похоже, сделано адекватно (как в Git, Monotone и прочих, где хэш гарантированно требуется проверяемым по содержанию конкретной ревизии). А вот то, что ты этого не знаешь, и то, что я про histedit вытащил только после долгой дискуссии, показывает, что твой опыт просто неприменим под мои задачи и подходы.

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

Да, кстати, а вот тебе похоже должен был бы понравиться этот https://www.mercurial-scm.org/wiki/MqTutorial инструмент. Он кстати пока входит в поставку, но обсуждается вопрос его удаления... )))

_>>Тут и наличие анонимных веток и их поведение при синхронизации (они просто все возникают у всех)
N>Я уже говорил, что в Git ты можешь потребовать синхронизации полного пучка веток, но по умолчанию это отключили в 2.2.

Я не об этом (тут понятно что всего лишь опция команды), а про то, как чужие ветки выглядят в твоём репозитории. )

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

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

приводил картинку того, что имею в виду. Предположим что ревизии 2 и 3 созданы на разных компьютерах. Как бы ты реализовал подобное с помощью git? )
N>Очевидно — fetch+merge. Если ты хочешь сказать, что тебя утомляет необходимость назвать принятую от другого ветку, то я могу только выразить соболезнования, но не согласиться.

Нуу покажи пример. Что бы git log --graph показал картинку аналогичную той моей (причём в каждом из двух репозиториев). И при этом прикинуть объём команд необходимый для этого. Могу сделать аналогичное для mercurial. )