Здравствуйте, netch80, Вы писали:
_>>Ну так это только в git надо корёжится (не допускать gc, непонятным образом искать id и т.п.), а в mercurial это всё идеально удобно. N>Если хочешь дальше общаться, прекращай это НЛП в виде регулярной мантры "идеально удобно", или я просто прекращу обсуждение и буду считать тебе техническое поражение. Надоело. Или мы говорим проверяемыми аргументами без вкусовщины (во что входит соответствие общепринятым терминам и распространённым практикам), или мне такое не подходит.
Вообще то как раз только что я и сделал попытку количественного анализа данного субъективного вопроса — предложил сравнить необходимые команды в разных системах для реализации одной и той же задачи. Однако ты её проигнорировал, без внятного объяснения.
_>> Вот последовательность команд в Mercurial: N>Тему веток я прокомментировал ровно один свой комментарий назад в этой ветке.
Я понял твои мысли там. Но непонятно какое они имеют отношение к вопросу сравнения числа команд для решения конкретной задачки. У тебя какие-то претензии к такому подходу? )
N>>>Удобства не увидел. Чтобы оно появилось, нужно, чтобы был смысл в параллельном развитии голов от одного разработчика и при этом переключаться между ними по идентификаторам, намеренно отказываясь от имён. Это уже религиозные заморочки, мне такое сложно понять. _>>Почему обязательно одного разработчика? ) N>Ну ok. От нескольких. И опять же всё без имён, только по идентификаторам коммитов. А потом за них же цепляться и сводить воедино.
Ну лично я делаю это правым кликом по соответствующей ревизии в визуальном дереве и выбором пункта "слить с локальной копией". ))) Однако и из консоли это всё делается тривиально, как раз благодаря командам типа heads.
_>>Ну а насчёт удобства... Про принцип Оккама не забываем! ) N>И что он тут даёт в твою пользу? В мою вижу — появилась излишняя сущность "безымянные цепочки" с диверсионными последствиями.
Как раз придумывание имени ветки, которая существует например только ради синхронизации — это и есть очевидно лишнее.
Здравствуйте, alex_public, Вы писали:
_>·>Столько ненужной и лишней терминологии просто из-за кривого дизайна системы. _>Рекомендую читать с начала: _>
_>The term branch is sometimes used for slightly different concepts. This may be confusing for new users of Mercurial.
_>Branches occur if lines of development diverge. The term "branch" may thus refer to a "diverged line of development". For Mercurial, a "line of development" is a linear sequence of consecutive changesets.
Это ещё сильнее запутывает. Вот в таком репозитории:
т.е. простая линейная история, никакой diverged line нет, но ветка release чуть старее чем development. Сколько тут веток? И как это следует из приведённой тобой цитаты?
Или вот такая история
Вроде это не linear sequence, сколько тут веток?
_>>>И в результате получают глупости типа описанных в последнем предложение по моей ссылке. ))) _>·>Которой ссылке? Я правильно понял, ты имеешь в виду что в официальной документации hg написана глупость? _>Нет, там корректно написано каким путём можно привести систему в глупое состояние. )
Ничего не понял. Давай конкретно. Приведи цитату, что такое глупое состояние системы и бывают ли в hg какие-то другие состояния?
_>>>А расскажи, чем по твоему неудобны глобальные имена веток? ) _>·>Тем что это противоречит распределённости. Лишняя сущность, которая нужна далеко не всегда. Что плохого в том, если два разработчика создадут ветки "experiment", а потом захотят обменяться? _>И в чём будет проблема с этим в Mercurial? )
Да, интересно как. У меня есть репо, у тебя есть репо. Мы оба делали какие-то свои эксперименты, у нас обоих есть ветки с именем "experiment", но совершенно разные по содержимому. Как мне взять твой experiment в свой репозиторий, чтобы не смешивать с моим experiment? В git можно например так:
git fetch <your_repo_url> experiment:alex_public_experiment
_>>>Про номера ревизий не понял в чём проблема, это всего лишь локальные хоткеи для удобства (если не хочешь, можешь вообще не обращать на них внимание) адресации. _>·>Ещё одна ненужная нашлёпка сбоку, унаследованная от cvcs. _>А людям удобно. ) Тем же кому не надо, ничем не мешает. Непонятно что плохого.
С толку сбивает. В git это гораздо проще: есть просто навигация по графу ревизий.
_>>>Ну так правильно, heads то показывает не все существующие ветки в репозитории, а только некое подмножество — не слитые. А heads <branchname> показывает ещё более мелкое подмножество — помеченные определённым именем. _>·>Объясни, каким словарём ты пользуешься, что словосочетание "branch heads" ты переводишь как "ветки"? Или в документаци, как всегда, глупость написана? _>Ну естественно что branch heads — это не ветки, а соответствующие ревизии. Но т.к. их число будет в точности равно числу не слитых веток, то думаю что моя фраза была вполне понятна.
Не будет. Пусть у тебя есть две ветки-в-официальном-понимании b1 и b2, каждая из них будет иметь по две головы. Количество веток-в-официальном-понимании будет всё равно две, а веток-alex_public-вида будет четыре. Команда "hg heads b1" выведет две головы.
Твоя фраза не понятна, ибо ты не используешься терминологией, принятой в документации hg.
_>>>Так а может ты пояснишь, какой аналог анонимных веток у нас в git? ) Т.е. что делать при нескольких параллельных изменения относительно одной родительской ревизии, обязательно заводить отдельную именованную ветку? ) _>·>А если не обязательно параллельных? _>·>В общем да, можно и ветку завести — ибо это ничего не стоит и никаких сложностей не создаёт. Это же не hg, где если заведёшь ветку, то это "навсегда". Собственно эта "фича" hg продиктована необходимостью — ветку завести не всегда возможно, вот и пришлось придумать новую сущность — головы. _>Никакой сущности "головы" в mercurial нет. ))) А команда heads просто показывает список ревизий без потомков (соответственно это получается список конечных ревизий, по одной для каждой ветки).
А о чём рассказывает статья https://www.mercurial-scm.org/wiki/Head ? Статья говорит, что голова — это ревизия без потомков. А ещё я забыл что есть понятие tip. А ещё этот зоопарк понятий:
head
a changeset that has no children
branch
the set of all changesets with the same branch name
branch head
a changeset in a branch that has no children in that branch (not the same as head!)
active branch head
a branch head that is also a head
inactive branch head
a branch head that has a child not in the same branch
closed branch head
a branch head with a closed marker
closed branch
a branch with only closed heads
Жуууть!
_>·>Ещё можно просто по sha1 обращаться. Можно reflog полистать, можно в stash закинуть. Вариантов куча. _>Ага, очень удобно. ) Да, и не забудь заблокировать git gc при этом. )))
Почему? gc соберёт только хлам 3-месячной давности. Если ты забыл что-то безымянное на 3 месяца, ты уже точно не вспомнишь что это было.
А вообще мы вроде говорили о "что-то быстренько попробовать прям щаз".
_>·>Если хочешь разобраться досконально, читай хелп на "git gc", флажок --auto. Там точно указаны правила. Используются несколько имперически подобранных параметров, чтобы в более менее стандартных ситуациях давать хороший результат, если что — можно подкрутить для особых случаев. Вроде очевидно, что "несколько мегабайт" это не то, о чём стоит волноваться. _>Я согласен, что для обычного пользователя это всё не принципиально. Но мы то рассуждаем об архитектурных принципах. И пока что выходит что на практике (а не в теории, где все тесты производятся после repack) подход mercurial лучше.
Ты не понял что-ли ещё? На практике repack происходит сам. На практике непакованный репозиторий найти — проблема.
_>·>Так новые ревизии не заставляют репозиторий распаковываться. То что запаковалось — так и остаётся запакованным. _>А я этого и не утверждал. Я говорил что размер снова вырастет через несколько новых ревизий. )
Чтобы репо в пакованном виде условных 5.8мб вырос до тех же условных 30мб меркуриала и ни разу не выполнился gc — не верю что такое часто случается на практике.
_>·>Разница есть, конечно, но не принципиальна... Вообще не понимаю причём тут бандлы, они от структуры репозитория не зависят. _>Потому что они идеально характеризуют тот объём данных, который необходимо переслать по сети для соответствующей синхронизации репозиториев. Можно конечно и честно по сети замерять, но это намного сложнее. Ну а соответственно размер этих файлов даёт представление о качестве алгоритмов эти двух систем... )
И что? 399 и 419 байт — и какие выводы из этой разницы ты сделаешь? Что неожиданного оказалось в этих цифрах для тебя?
Ещё раз — то что передаётся по сети никак не зависит от формата хранилища.
_>>>Ну для начала с "много места" мы ещё и не разобрались. И кстати говоря у всех подходов есть свои недостатки. Даже если взять за основу идею с repack'ом, то помимо проблем с расписанием данной работы, данная техника к примеру блокирует возможность инкрементальных бэкапов хранилища. _>·>Не блокирует. Просто иногда после repack придётся новые паки бэкапить, старые удалять, вот и всё. А вообще не проще ли --mirror использовать или тупо rsync? _>Ну о пользе и недостатках инкрементального бэкапа можно отдельно говорить. Но факт в том, что операция repack в git сильно вредит данной технике.
А вообще любопытно... Зачем вообще в dvcs нужен инкрементальный бэкап?
Но если так надо, то проще git bundle для этого использовать.
А вот инкрементально бэкапить (особенно hot repo) файлы hg я бы не стал... Вообще — погугли. Принципы бэкапов hg и git ничем не отличаются.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Dziman, Вы писали:
a>> 1. Имена веток — это просто неизменяемый атрибут ревизий с особым свойством, он автоматически передаётся всем наследникам данной ревизии (если руками не указано иного). D>А чем это полезно? На пальцах.
Ну то что это неизменяемый атрибут (а не указатель, как bookmark, или изменяемый tag), даёт нам возможность гарантированного сохранения всей истории, в отличие от того же git'a. Вот тут https://habrahabr.ru/post/123700/ можно глянуть картинки, демонстрирующие эту разницу на примере.
Ну а возможность наследования значения в сочетание с автоматическим ветвлением даёт возможность легко делать такие расклады:
| |
o 5 |
|\ |
| \ |
| \|
| o 4
| /\
| / \
| o 2 o 3
| \ /
| \/
| o 1
| |
relese develop
в которой ревизии 1, 2, 3, 4 носят имя ветки develop, а ревизия 5 имя ветки release..
D>Ну и чтобы 2 раза не вставать: если я когда-то создал ветку с именем branch1, то я больше никогда не смогу создать другую ветку с таким же именем? И более того имена глобальны для всех репо?
Реальная ветка создаётся не командой branch, а соответствующей командой commit. ) И да, имена глобальные. )
Здравствуйте, alex_public, Вы писали:
_>в которой ревизии 1, 2, 3, 4 носят имя ветки develop, а ревизия 5 имя ветки release..
Собственно в этом от git и отличается. Понятие "ветка" в hg не имеет никакого отношения к структуре истории, как в других vcs, а просто некая метка, наляпываемая на каждую ревизию.
Какое знание несёт информация, что ревизия 2 была создана именно в ветке develop, если эта же ревизия существует и в release?
Этого же эффекта можно добиться помещая имя текущей ветки в коммент коммита (можно хук сделать). Но зачем из буханки делать троллейбус?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
·>т.е. простая линейная история, никакой diverged line нет, но ветка release чуть старее чем development. Сколько тут веток? И как это следует из приведённой тобой цитаты?
Как это нет? ) А разве release и development не ответвляются от некой неназванной ветки?) Или я неправильно понял картинку (вообще непривычно читать историю слева направо)? Если правильно, то тогда имеем 3 ветки.
·>Или вот такая история ·>
·>Вроде это не linear sequence, сколько тут веток?
А тут одна ветка отделяется от другой (в которой было разветвление)? И что? )
_>>Нет, там корректно написано каким путём можно привести систему в глупое состояние. ) ·>Ничего не понял. Давай конкретно. Приведи цитату, что такое глупое состояние системы и бывают ли в hg какие-то другие состояния?
Глупое состояние было в репозитории с которым игрался netch80. А в данном куске документации подробно объяснялось как он его добился.
_>>И в чём будет проблема с этим в Mercurial? ) ·>Да, интересно как. У меня есть репо, у тебя есть репо. Мы оба делали какие-то свои эксперименты, у нас обоих есть ветки с именем "experiment", но совершенно разные по содержимому. Как мне взять твой experiment в свой репозиторий, чтобы не смешивать с моим experiment? В git можно например так: ·>git fetch <your_repo_url> experiment:alex_public_experiment
У тебя будет просто две ветки с именем experiment после синхронизации. )
_>>Ну естественно что branch heads — это не ветки, а соответствующие ревизии. Но т.к. их число будет в точности равно числу не слитых веток, то думаю что моя фраза была вполне понятна. ·>Не будет. Пусть у тебя есть две ветки-в-официальном-понимании b1 и b2, каждая из них будет иметь по две головы. Количество веток-в-официальном-понимании будет всё равно две, а веток-alex_public-вида будет четыре. Команда "hg heads b1" выведет две головы. ·>Твоя фраза не понятна, ибо ты не используешься терминологией, принятой в документации hg.
Судя по твоему следующему сообщению ты уже сам всё понял, но всё же отвечу: будет 4 ветки, каждая пара из которых будет с одним именем. И команда heads покажет все 4. )
_>>Никакой сущности "головы" в mercurial нет. ))) А команда heads просто показывает список ревизий без потомков (соответственно это получается список конечных ревизий, по одной для каждой ветки). ·>А о чём рассказывает статья https://www.mercurial-scm.org/wiki/Head ? Статья говорит, что голова — это ревизия без потомков. А ещё я забыл что есть понятие tip. А ещё этот зоопарк понятий: ·>... ·>Жуууть!
Ну а я что сказал? ) Список ревизий без потомков. ) А tip — это всего лишь автоматический Tag, опять же для удобства. )
_>>Я согласен, что для обычного пользователя это всё не принципиально. Но мы то рассуждаем об архитектурных принципах. И пока что выходит что на практике (а не в теории, где все тесты производятся после repack) подход mercurial лучше. ·>Ты не понял что-ли ещё? На практике repack происходит сам. На практике непакованный репозиторий найти — проблема.
К тому моменты, когда он происходит (при дефолтных настройках) размер репозитория уходит далеко в небеса. Именно об этом и говорило то тестирование по моей ссылке (с графиками и т.п.). Они пытались исправить это настройкой вида "делать git-gc через каждые несколько фиксаций". Тогда всё было нормально с размером, но скорость резко проседала даже по сравнению с Mercurial.
_>>Потому что они идеально характеризуют тот объём данных, который необходимо переслать по сети для соответствующей синхронизации репозиториев. Можно конечно и честно по сети замерять, но это намного сложнее. Ну а соответственно размер этих файлов даёт представление о качестве алгоритмов эти двух систем... ) ·>И что? 399 и 419 байт — и какие выводы из этой разницы ты сделаешь? Что неожиданного оказалось в этих цифрах для тебя?
При мелком апдейте основной размер идёт на накладные расходы. Я как раз потому и сказал большой файл засунуть, чтобы было видно. )
·>Ещё раз — то что передаётся по сети никак не зависит от формата хранилища.
Зато зависит от архитектуры системы.
_>>Ну о пользе и недостатках инкрементального бэкапа можно отдельно говорить. Но факт в том, что операция repack в git сильно вредит данной технике. ·>А вообще любопытно... Зачем вообще в dvcs нужен инкрементальный бэкап? ·>Но если так надо, то проще git bundle для этого использовать. ·>А вот инкрементально бэкапить (особенно hot repo) файлы hg я бы не стал... Вообще — погугли. Принципы бэкапов hg и git ничем не отличаются.
Здравствуйте, ·, Вы писали:
·>Этого же эффекта можно добиться помещая имя текущей ветки в коммент коммита (можно хук сделать). Но зачем из буханки делать троллейбус?
Можно и так))) Но тогда с этим не смогут работать различные команды (типа heads, pull/push и т.п.).
_>·>т.е. простая линейная история, никакой diverged line нет, но ветка release чуть старее чем development. Сколько тут веток? И как это следует из приведённой тобой цитаты? _>Как это нет? ) А разве release и development не ответвляются от некой неназванной ветки?) Или я неправильно понял картинку (вообще непривычно читать историю слева направо)? Если правильно, то тогда имеем 3 ветки.
Нет, не ответвляются. Точнее, если переводить дословно "diverged" — не расходятся. Тривиальная линейная история. Звёздочки это ревизии. А линии — ну просто линии, чтобы было понятно что куда относится. Т.е. этот рисунок отображает тот факт, что release был сделан 4 ревизии назад от development. Или, иначе говоря, с тех пор как мы зарелизились, было надевелопено ещё четыре новые ревизии. Это самый простой рисунок для этой ситуации, именно он такой и будет в git. В hg он будет сложнее, с лишними наворотами.
_>·>Или вот такая история _>·>
_>·>Вроде это не linear sequence, сколько тут веток? _>А тут одна ветка отделяется от другой (в которой было разветвление)? И что? )
Это не linear sequence, как это согласуется приведённой тобой цитате?
_>>>Нет, там корректно написано каким путём можно привести систему в глупое состояние. ) _>·>Ничего не понял. Давай конкретно. Приведи цитату, что такое глупое состояние системы и бывают ли в hg какие-то другие состояния? _>Глупое состояние было в репозитории с которым игрался netch80. А в данном куске документации подробно объяснялось как он его добился.
А толком можно объяснить? Где игрался, как игрался, почему глупое? Как ещё можно играться? Если у тебя есть какая-то мысль, сформулируй её чётко.
_>·>Да, интересно как. У меня есть репо, у тебя есть репо. Мы оба делали какие-то свои эксперименты, у нас обоих есть ветки с именем "experiment", но совершенно разные по содержимому. Как мне взять твой experiment в свой репозиторий, чтобы не смешивать с моим experiment? В git можно например так: _>·>git fetch <your_repo_url> experiment:alex_public_experiment _>У тебя будет просто две ветки с именем experiment после синхронизации. )
Нет, rtfm. В моём репо будет моя ветка "experiment", и твоя "alex_public_experiment".
А в hg что будет?
_>·>Не будет. Пусть у тебя есть две ветки-в-официальном-понимании b1 и b2, каждая из них будет иметь по две головы. Количество веток-в-официальном-понимании будет всё равно две, а веток-alex_public-вида будет четыре. Команда "hg heads b1" выведет две головы. _>·>Твоя фраза не понятна, ибо ты не используешься терминологией, принятой в документации hg. _>Судя по твоему следующему сообщению ты уже сам всё понял, но всё же отвечу: будет 4 ветки, каждая пара из которых будет с одним именем. И команда heads покажет все 4. )
Если ты читал документацию, тебя не должно затруднить привести цитату, что ветки-alex_public-вида называются именно словом "ветка". Я читал документацию, это называется не ветки, а головы.
_>·>А о чём рассказывает статья https://www.mercurial-scm.org/wiki/Head ? Статья говорит, что голова — это ревизия без потомков. А ещё я забыл что есть понятие tip. А ещё этот зоопарк понятий: _>·>... _>·>Жуууть! _>Ну а я что сказал? ) Список ревизий без потомков. )
Ты говорил: «Никакой сущности "головы" в mercurial нет». В оф.документации есть, однако. Даже команда есть такая. Я не понимаю зачем ты вводишь в заблуждение.
_> А tip — это всего лишь автоматический Tag, опять же для удобства. )
tag вообще-то неизменяемая сущность во всех других мне известных vcs. Так что и таги в hg оказывается какие-то особенные.
А tip значит не просто некий таг как и все, а особенный, "автоматический", ещё одна сущность. Бардак.
_>·>Ты не понял что-ли ещё? На практике repack происходит сам. На практике непакованный репозиторий найти — проблема. _>К тому моменты, когда он происходит (при дефолтных настройках) размер репозитория уходит далеко в небеса. Именно об этом и говорило то тестирование по моей ссылке (с графиками и т.п.). Они пытались исправить это настройкой вида "делать git-gc через каждые несколько фиксаций". Тогда всё было нормально с размером, но скорость резко проседала даже по сравнению с Mercurial.
Не знаю, странная ссылка была. Я мало что понял что и как тестировалось, да ещё и 5 лет назад. Хочется более-менее реальные тесты увидеть. Гигахостинги типа github говорят о том, что это значительной проблемой не является.
И вообще, если просто почитать выводы: "If you need the fastest system and don’t mind occassional performance glitches and volatile repository sizes, git is the way to go", ибо я, как юзер, предпочитаю работать с быстрой системой. "If you need reliable performance and space requirements, Mercurial is the better choice" — это проблема серверов и железа, которое сейчас дешевое.
_>>>Потому что они идеально характеризуют тот объём данных, который необходимо переслать по сети для соответствующей синхронизации репозиториев. Можно конечно и честно по сети замерять, но это намного сложнее. Ну а соответственно размер этих файлов даёт представление о качестве алгоритмов эти двух систем... ) _>·>И что? 399 и 419 байт — и какие выводы из этой разницы ты сделаешь? Что неожиданного оказалось в этих цифрах для тебя? _>При мелком апдейте основной размер идёт на накладные расходы. Я как раз потому и сказал большой файл засунуть, чтобы было видно. )
Так я засунул ~1мб текстовый файл. Изменение я делал добавлением новой строчки в конец "echo boo >> file", как ты и просил в описании эксперимента.
_>·>Ещё раз — то что передаётся по сети никак не зависит от формата хранилища. _>Зато зависит от архитектуры системы.
Каким образом? К чему эта тупая упёртость? Я ж привёл тебе результат эксперимента — 399 и 419 байт. Проведи эксперимент сам, если не веришь.
_>>>Ну о пользе и недостатках инкрементального бэкапа можно отдельно говорить. Но факт в том, что операция repack в git сильно вредит данной технике. _>·>А вообще любопытно... Зачем вообще в dvcs нужен инкрементальный бэкап? _>·>Но если так надо, то проще git bundle для этого использовать. _>·>А вот инкрементально бэкапить (особенно hot repo) файлы hg я бы не стал... Вообще — погугли. Принципы бэкапов hg и git ничем не отличаются. _>Речь про бэкап сервера, а не про работу с git. )
Что за "бэкап сервера"? И чем он будет принципиально отличаться в случае git и hg?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, alex_public, Вы писали:
_>·>Этого же эффекта можно добиться помещая имя текущей ветки в коммент коммита (можно хук сделать). Но зачем из буханки делать троллейбус? _>Можно и так))) Но тогда с этим не смогут работать различные команды (типа heads, pull/push и т.п.).
Команда heads, конечно работать не будет, ибо такой команды в git нет, так как этого бреда с многоголовыми ветками нет. Неслитые ветки в git можно посмотреть, как ни странно, командой branch с ключиком "--no-merged".
А с push/pull что случится-то?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Нет, не ответвляются. Точнее, если переводить дословно "diverged" — не расходятся. Тривиальная линейная история. Звёздочки это ревизии. А линии — ну просто линии, чтобы было понятно что куда относится. Т.е. этот рисунок отображает тот факт, что release был сделан 4 ревизии назад от development. Или, иначе говоря, с тех пор как мы зарелизились, было надевелопено ещё четыре новые ревизии. Это самый простой рисунок для этой ситуации, именно он такой и будет в git. В hg он будет сложнее, с лишними наворотами.
А, всё, я понял что ты нарисовал. Правда не знаю зачем применять для такого именованные ветки (когда нет реальных разветвлений), но если очень хочется, то в mercurial можно без проблем и оно прямо так и будет выглядеть. ) И даже меньше команд чем в git понадобится. )))
_>>·>Вроде это не linear sequence, сколько тут веток? _>>А тут одна ветка отделяется от другой (в которой было разветвление)? И что? ) ·>Это не linear sequence, как это согласуется приведённой тобой цитате?
Я просто не понял твой формат рисования) Теперь понял)
Но кстати вопрос "сколько веток" некорректен для некого отрезка истории, т.к. на его протяжение это число может меняться. Например тут в начале одна ветка, потом она разветвляется на две, а потом снова сливается в одну. Данный вопрос корректен только для фиксированного момента времени.
_>>Глупое состояние было в репозитории с которым игрался netch80. А в данном куске документации подробно объяснялось как он его добился. ·>А толком можно объяснить? Где игрался, как игрался, почему глупое? Как ещё можно играться? Если у тебя есть какая-то мысль, сформулируй её чётко.
Это всё было в сообщениях выше) Он спрашивал каким образом получилась некая ересь, так вот данная фраза из документации была объяснением. )
_>>У тебя будет просто две ветки с именем experiment после синхронизации. ) ·>Нет, rtfm. В моём репо будет моя ветка "experiment", и твоя "alex_public_experiment". ·>А в hg что будет?
Я вообще то про Mercurial и говорил. )))
_>>Судя по твоему следующему сообщению ты уже сам всё понял, но всё же отвечу: будет 4 ветки, каждая пара из которых будет с одним именем. И команда heads покажет все 4. ) ·>Если ты читал документацию, тебя не должно затруднить привести цитату, что ветки-alex_public-вида называются именно словом "ветка". Я читал документацию, это называется не ветки, а головы.
Голова — это одна ревизия, не путай с ветками (они состоят из набора ревизий). ) Ну а что касается цитаты... Я тебе уже в который раз говорю прочитать внимательно эту https://www.mercurial-scm.org/wiki/Branch ссылку. Там же всего лишь пара страниц, а ты уже в который раз не можешь осилить. ))) Например:
Strictly speaking, a branch is created when a user creates a new changeset C2 in a repository R0, if its parent changeset P already has a child C1, thus adding a second child changeset C2 to that parent P. This adds a new head to R0.
или
As such, each changeset in Mercurial forms an element of a branch. A changeset thus can be said to "belong to a branch". Per that definition, a branch is simply a linear sequence of changesets.
Ещё требуются пояснения? ) Думаю вполне видно, что никаких намёков на именованные ветки тут нет.
_>>Ну а я что сказал? ) Список ревизий без потомков. ) ·>Ты говорил: «Никакой сущности "головы" в mercurial нет». В оф.документации есть, однако. Даже команда есть такая. Я не понимаю зачем ты вводишь в заблуждение.
Это не отдельная сущность, а просто название ревизии без потомков. Т.е. этот "термин" можно спокойно и в git применять. )))
_>> А tip — это всего лишь автоматический Tag, опять же для удобства. ) ·>tag вообще-то неизменяемая сущность во всех других мне известных vcs. Так что и таги в hg оказывается какие-то особенные. ·>А tip значит не просто некий таг как и все, а особенный, "автоматический", ещё одна сущность. Бардак.
Кошмар, кошмар. ))) Нельзя ничего добавлять в систему для удобства пользоваться. Пускай он лучше побольше сам работает, не развалится, да? )))
·>Не знаю, странная ссылка была. Я мало что понял что и как тестировалось, да ещё и 5 лет назад. Хочется более-менее реальные тесты увидеть. Гигахостинги типа github говорят о том, что это значительной проблемой не является. ·>И вообще, если просто почитать выводы: "If you need the fastest system and don’t mind occassional performance glitches and volatile repository sizes, git is the way to go", ибо я, как юзер, предпочитаю работать с быстрой системой. "If you need reliable performance and space requirements, Mercurial is the better choice" — это проблема серверов и железа, которое сейчас дешевое.
Ну так я же это тестирование привёл не в качестве аргумента за использование одной или другой системы (в этом смысле я уже давно сказал, что подобные вопросы у них одинаково удовлетворительно для пользователя решены и есть смысл выбирать только по вкусу удобства работы с системой команд), а в контексте нашего обсуждения преимуществ разных архитектур. Это не я начал первым утверждать, что у Git архитектура более совершенная. Я лишь указал, что на практике эта вроде как совершенная архитектура проигрывает. )))
_>>При мелком апдейте основной размер идёт на накладные расходы. Я как раз потому и сказал большой файл засунуть, чтобы было видно. ) ·>Так я засунул ~1мб текстовый файл. Изменение я делал добавлением новой строчки в конец "echo boo >> file", как ты и просил в описании эксперимента.
Так я и говорю, что смысл имеет сравнение только цифр для пакета с двумя ревизиями (т.к. там мегабайтный файл), а в пакете с одной ревизией большую часть места занимают накладные расходы на формат пакета. Поэтому там и разницы особой нет. А вот при наличие большого объёма данных сразу видна разница в 1,5 раза.
_>>Зато зависит от архитектуры системы. ·>Каким образом? К чему эта тупая упёртость? Я ж привёл тебе результат эксперимента — 399 и 419 байт. Проведи эксперимент сам, если не веришь.
У тебя всё верно, но я говорю об измерение пакетов с двумя ревизиями. ) И от чего по твоему оно зависит, если нет архитектуры системы? )
_>>Речь про бэкап сервера, а не про работу с git. ) ·>Что за "бэкап сервера"? И чем он будет принципиально отличаться в случае git и hg?
Эмм, тебе не знакомо понятие бэкапа сервера? Не важно инкрементального или нет...
Отличие у git и hg будет в том, что в случае инкрементального бэкапа хранилище git'a после repack'а придётся копировать всё заново (хотя там может добавилась всего пара ревизий), а в случае hg будет скопировано только реальное изменение (новые ревизии). В случае большой истории в репозитории это может быть очень существенная разница.
Здравствуйте, ·, Вы писали:
_>>·>Этого же эффекта можно добиться помещая имя текущей ветки в коммент коммита (можно хук сделать). Но зачем из буханки делать троллейбус? _>>Можно и так))) Но тогда с этим не смогут работать различные команды (типа heads, pull/push и т.п.). ·>Команда heads, конечно работать не будет, ибо такой команды в git нет, так как этого бреда с многоголовыми ветками нет. Неслитые ветки в git можно посмотреть, как ни странно, командой branch с ключиком "--no-merged". ·>А с push/pull что случится-то?
А причём тут git? ) Я отвечал на твой как бы юмор, что можно было бы сделать реализацию имён веток в Mercurial через добавления этого имени в комментарий ревизии через хук. Так вот я и ответил, что да, теоретически это было бы похоже, но тогда перестали бы работать возможности многих команд Mercurial, умеющих принимать имя ветки в качестве параметра.
Что касается git'a, то его вообще смешно обсуждать в данном контексте, т.к. он банально не умеет создавать ветки без имён. )
Здравствуйте, 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 такой фичи я уже упоминал.
Здравствуйте, alex_public, Вы писали:
_>>>Отдельно в Mercurial существует ещё несколько понятий, которые ты возможно путаешь: _>>>1. Имена веток — это просто неизменяемый атрибут ревизий с особым свойством, он автоматически передаётся всем наследникам данной ревизии (если руками не указано иного). N>>О. Вот тут твоя идеальная картина вдруг резко прекращается и начинается тысяча голодных дьяволов в мелочах. Начиная с того, что команда branch работает почему-то с вот этими "неизменяемыми атрибутами ревизий с особым свойством", что во всех найденных howto и объяснениях именно это называется веткой, что ты в начале дискуссии упорно доказывал, что именно это и есть ветки, а не то, что ты вдруг начал писать в этом постинге, и прочая, и прочая, и прочая. _>Так где оно называется то так? Скажем при описание какой-нибудь команды с возможным параметром в виде этого самого атрибута (введённого специально для идентификации неанонимных веток). Ты думаешь кто-то будет писать "передаём команде специальный атрибут branch1, идентифицирующий нашу ветку"? Естественно все пишут "передаём команде ветку branch1".
А должно быть "передаём команде ярлык branch1", например. Но не ветку. Но этот твой пример ещё интереснее. Я приводил диаграмму, где этим тегом пометил два коммита в разных ветках. Что команда сделает? Если отфильтрует из всего репо или от указанной точки роста все такие коммиты, то ещё понятно, но какой смысл, если они могут не входить в DAG с общей головой? А если что-то сделать с потенциальной головой, то если их две, какое будет принято решение?
_>>>2. Закладки — просто символические указатели (опциональные) на последнюю (автоматически перескакивают при фиксации) ревизию в ветках. По сути является аналогом веток в Git. Были введены не сразу (видимо как раз для удобства людей переходящих с Git). N>>Аналогом веток почти _везде_ кроме Hg. Начиная с того же CVS. Частично — и для SVN, если считать веткой базовый каталог и учитывать возможность прыжка между такими базами. _>Неизменность истории мне нравится больше)
А при чём тут вообще неизменность истории?
_>Ну вообще то раньше (до популярности гитхаба) со старых систем как раз чаще переходили на Mercurial в силу более привычной системы команд. Сейчас же из-за распиаренности гитхаба чаще переходят на git и страдают потом с ним. )
Я уже предупреждал на тему эмоциональных крючков. Если ты не можешь обойтись без этих "идеально", "страдают" и т.п., говоря о чём-то кроме собственного опыта и опыта тех (явно названных), кто тебе явно доверил такое право, то прекращай дискуссию со мной.
И у меня впечатление о процессах в период бурного роста популярности этих систем — заметно противоположное. Возможно, в Windows среде происходит именно так. В моих краях если что-то и влияло на популярность Git, то это авторитет Линуса. Но он проектировал Git с точки зрения требуемых ему сценариев, в которые входит — основные принципиальные особенности:
* категорическая ориентированность на содержание коммита, независимо от конкретного места его размещения в истории, в конкретном репо и т.п. (делает любые id локальными)
* возможность редактирования уже сформированных предложений, даже длинных цепочек (чаще всего через дискуссию в LKML и родственные рассылки)
* эффективное слияние многих источников за раз (многих — это до сотен)
* подчинённые деревья, выживающие после upstream rebase
и мне все полученные от этого плюшки оказались выгодными, а сопутствующие недостатки — несущественными.
_>Ну это естественно если руками в консоли работают. При классической работе через плагин в IDE разницы между этими двумя DVCS почти не будет. N>>К тому же, сам по себе сценарий типа "тут переехали назад по истории и начали рост от нового места" без внятной формулировки причины, зачем нужен этот самый рост, для меня выглядит банально нелепым. Если есть причина, надо её назвать хотя бы для себя и хотя бы для того, чтобы в истории не болталась забытая цепочка. А если она названа — она и будет названием ветки в общепринятом стиле. _>А если причиной развилки будет всего лишь синхронизация изменений с двух разных машин? )
Притянул состояние с другой машины — да, явно назвав, иначе несекьюрно — и начал играться.
А при многих таких нескольких — даже в пределах одного отдела — название ветки начинает играть роль собственно принципиального указания, от кого взято конкретное изменение, потому что понять это по содержанию уже невозможно.
Безымянная ветка для этого становится случаем ничтожной экономии усилий на частный случай, когда таких источников считанные единицы, они не конфликтуют (до неразличения) по смыслу с любыми локальными изменениями (а программист ещё не устал и способен отличать источники по их виду), используемые средства явно показывают все эти головы и их не настолько много, чтобы не вмещались в интерфейс... возможно, ты и твоя команда способны всё это осиливать, но я предпочту тратить мысленные усилия на что-то более для меня полезное.
N>>Ну, если ты знаешь, как провести эти тесты — покажи скрипты и результаты. Не думаю, что они покажут что-то принципиально важное (я лучше бы для сравнения взял результат перегонки чего-то открытого активно разрабатываемого), но просто покрасоваться цифрами — сгодится. _>Ну тут уже кидали результаты. У меня в принципе похожие — у Mercurial раза в 1,5 меньше получаются пакеты изменений. ) Т.е. где-то так же и сеть загружается при синхронизации.
При остальных плюшках Git разница не принципиальна, но имеет смысл попинать авторов.
Здравствуйте, alex_public, Вы писали:
_>А причём тут git? ) Я отвечал на твой как бы юмор, что можно было бы сделать реализацию имён веток в Mercurial через добавления этого имени в комментарий ревизии через хук. Так вот я и ответил, что да, теоретически это было бы похоже, но тогда перестали бы работать возможности многих команд Mercurial, умеющих принимать имя ветки в качестве параметра.
С чего бы это они перестали? Сейчас они анализируют отдельный атрибут, некорректно названный "branch". А могли грепать текст комментария (чуть менее эффективно на больших комментариях в стиле linux kernel, где к 2-строчному изменению может прилагаться oops, стартовый dmesg, разъяснение на пальцах на две страницы и два десятка acked-by) или сделать универсальный механизм атрибутов ревизии (полезен не только ради ярлыка системы "ветка", но и для кучи других применений).
Здравствуйте, alex_public, Вы писали:
D>>А чем это полезно? На пальцах. _>Ну то что это неизменяемый атрибут (а не указатель, как bookmark, или изменяемый tag), даёт нам возможность гарантированного сохранения всей истории, в отличие от того же git'a.
"Гарантированное сохранение всей истории" обеспечивается не этим атрибутом, а тем, что откат невозможен (даже на одну ревизию назад это "roll back the last transaction (DANGEROUS) (DEPRECATED)") (не хватает ещё ®™ после этих Caps ), правка более чем на одну ревизию вообще ничем не делается, даже если ты понял, что сотворил дикую чушь (если верить докам) Это убойное отличие от Git, который действует по принципу "вы локально можете изменять что угодно, ваши проблемы, но попробуйте теперь заставить других это принять".
(Положительным следствием этого для Git является то, что можно делать несколько подходов к одной задаче, уточняя реализацию в виде цепочки коммитов, каждый из которых сам по себе ясен, прямолинеен и решает только одну задачу. Мне неоднократно приходилось (в смысле, для такой понятности и своего удобства) вставлять в эту цепочку в начало какие-то изменения, чаще всего рефакторинг для более полного охвата задачи одного коммита. С тем, что в Hg после команды commit уже ничего не изменить, разве что породить новую ветку, это различие фатально. Но и порождение новой ветки даёт интересный эффект — а почему бы не изменить имя старой? Ан нет, нельзя, если по канонам.)
А сам по себе дополнительный атрибут "branch" у ревизии никак не влияет на её присутствие в финальной истории — ни в плюс, ни в минус.
_>Вот тут https://habrahabr.ru/post/123700/ можно глянуть картинки, демонстрирующие эту разницу на примере.
Сами по себе вопросы, которые там ставят — "на какую ветку было зафиксировано изменение ab3e2afd?" — показывают концентрацию на понятии "ветка" вместо цели самого изменения (которое обычно в корпоративной среде реализуется в виде имени тикета, под который делается изменение). При том, что в сообщении коммита можно записать что угодно, это становится подгонкой под заранее известный результат.
Здравствуйте, 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 коммитов назад — ты в любом интерфейсе вначале будешь долго мотать, чтобы её найти, или он будет показывать растянутые линии. А если таких несколько, то уже начнётся постоянная путаница, где чьи изменения и что из них надо принимать. Идею оптимизации на набор двух символов я понимаю, но принять её как-то сложно.
Здравствуйте, alex_public, Вы писали:
_>·>Нет, не ответвляются. Точнее, если переводить дословно "diverged" — не расходятся. Тривиальная линейная история. Звёздочки это ревизии. А линии — ну просто линии, чтобы было понятно что куда относится. Т.е. этот рисунок отображает тот факт, что release был сделан 4 ревизии назад от development. Или, иначе говоря, с тех пор как мы зарелизились, было надевелопено ещё четыре новые ревизии. Это самый простой рисунок для этой ситуации, именно он такой и будет в git. В hg он будет сложнее, с лишними наворотами. _>А, всё, я понял что ты нарисовал. Правда не знаю зачем применять для такого именованные ветки (когда нет реальных разветвлений), но если очень хочется, то в mercurial можно без проблем и оно прямо так и будет выглядеть. )
Потому что ветки обычно имеют некий смысл, связанный с процессом разработки, а не с текущей структурой истории. Нужны же ветки для того, чтобы понимать что у нас сейчас release, а что development. А разветвление расхождение веток это текущее состояние истории.
_> И даже меньше команд чем в git понадобится. )))
Покажи, плз. Насколько я знаю в hg без коммита ветку не создать.
_>>>·>Вроде это не linear sequence, сколько тут веток? _>>>А тут одна ветка отделяется от другой (в которой было разветвление)? И что? ) _>·>Это не linear sequence, как это согласуется приведённой тобой цитате? _>Я просто не понял твой формат рисования) Теперь понял) _>Но кстати вопрос "сколько веток" некорректен для некого отрезка истории, т.к. на его протяжение это число может меняться. Например тут в начале одна ветка, потом она разветвляется на две, а потом снова сливается в одну. Данный вопрос корректен только для фиксированного момента времени.
Мой вопрос в том, что имеется в виду в приведённой тобой документации: «"line of development" is a linear sequence of consecutive changesets». Где в приведённом мной графе истории line of develpment? Что есть head? Что есть branch?
_>>>Глупое состояние было в репозитории с которым игрался netch80. А в данном куске документации подробно объяснялось как он его добился. _>·>А толком можно объяснить? Где игрался, как игрался, почему глупое? Как ещё можно играться? Если у тебя есть какая-то мысль, сформулируй её чётко. _>Это всё было в сообщениях выше) Он спрашивал каким образом получилась некая ересь, так вот данная фраза из документации была объяснением. )
Не понял я, что именно ты имеешь в виду.
_>>>У тебя будет просто две ветки с именем experiment после синхронизации. ) _>·>Нет, rtfm. В моём репо будет моя ветка "experiment", и твоя "alex_public_experiment". _>·>А в hg что будет? _>Я вообще то про Mercurial и говорил. )))
Ааа. Понял. Хорошо, как в mercurial отличать мой "experiment" от твоего?
_>>>Судя по твоему следующему сообщению ты уже сам всё понял, но всё же отвечу: будет 4 ветки, каждая пара из которых будет с одним именем. И команда heads покажет все 4. ) _>·>Если ты читал документацию, тебя не должно затруднить привести цитату, что ветки-alex_public-вида называются именно словом "ветка". Я читал документацию, это называется не ветки, а головы.
_>Голова — это одна ревизия, не путай с ветками (они состоят из набора ревизий). ) Ну а что касается цитаты... Я тебе уже в который раз говорю прочитать внимательно эту https://www.mercurial-scm.org/wiki/Branch ссылку. Там же всего лишь пара страниц, а ты уже в который раз не можешь осилить. ))) Например: _>
_>Strictly speaking, a branch is created when a user creates a new changeset C2 in a repository R0, if its parent changeset P already has a child C1, thus adding a second child changeset C2 to that parent P. This adds a new head to R0.
Или, иначе говоря, выразить тот факт, что мы зарелизили всё что надевелопили.
_>или _>
_>As such, each changeset in Mercurial forms an element of a branch. A changeset thus can be said to "belong to a branch". Per that definition, a branch is simply a linear sequence of changesets.
_>Ещё требуются пояснения? ) Думаю вполне видно, что никаких намёков на именованные ветки тут нет.
Не осиливаю потому что полная мешанина из терминов. Чем тогда бранч отличается от "line of development"?
_>>>Ну а я что сказал? ) Список ревизий без потомков. ) _>·>Ты говорил: «Никакой сущности "головы" в mercurial нет». В оф.документации есть, однако. Даже команда есть такая. Я не понимаю зачем ты вводишь в заблуждение. _>Это не отдельная сущность, а просто название ревизии без потомков. Т.е. этот "термин" можно спокойно и в git применять. )))
Бранч может иметь несколько их. В этом и путаница, которая требует новой сущности. В гите этот термин бессмысленен.
_>>> А tip — это всего лишь автоматический Tag, опять же для удобства. ) _>·>tag вообще-то неизменяемая сущность во всех других мне известных vcs. Так что и таги в hg оказывается какие-то особенные. _>·>А tip значит не просто некий таг как и все, а особенный, "автоматический", ещё одна сущность. Бардак. _>Кошмар, кошмар. ))) Нельзя ничего добавлять в систему для удобства пользоваться. Пускай он лучше побольше сам работает, не развалится, да? )))
Конечно нельзя, если можно не добавлять, иначе Оккам бритвочкой полоснёт. Никакого удобства.. путаница только — вроде бы и тег, но какой-то особенный...
_>·>Не знаю, странная ссылка была. Я мало что понял что и как тестировалось, да ещё и 5 лет назад. Хочется более-менее реальные тесты увидеть. Гигахостинги типа github говорят о том, что это значительной проблемой не является. _>·>И вообще, если просто почитать выводы: "If you need the fastest system and don’t mind occassional performance glitches and volatile repository sizes, git is the way to go", ибо я, как юзер, предпочитаю работать с быстрой системой. "If you need reliable performance and space requirements, Mercurial is the better choice" — это проблема серверов и железа, которое сейчас дешевое. _>Ну так я же это тестирование привёл не в качестве аргумента за использование одной или другой системы (в этом смысле я уже давно сказал, что подобные вопросы у них одинаково удовлетворительно для пользователя решены и есть смысл выбирать только по вкусу удобства работы с системой команд), а в контексте нашего обсуждения преимуществ разных архитектур. Это не я начал первым утверждать, что у Git архитектура более совершенная. Я лишь указал, что на практике эта вроде как совершенная архитектура проигрывает. )))
Этот конкретный пример не убедительный, ибо непонятно как мерили и как воспроизвести результат. А так я и не отрицаю, что можно найти такие условия, когда эта архитектура будет вести себя хуже. "Хррр... — сказала японская бензопила."
_>>>При мелком апдейте основной размер идёт на накладные расходы. Я как раз потому и сказал большой файл засунуть, чтобы было видно. ) _>·>Так я засунул ~1мб текстовый файл. Изменение я делал добавлением новой строчки в конец "echo boo >> file", как ты и просил в описании эксперимента. _>Так я и говорю, что смысл имеет сравнение только цифр для пакета с двумя ревизиями (т.к. там мегабайтный файл), а в пакете с одной ревизией большую часть места занимают накладные расходы на формат пакета. Поэтому там и разницы особой нет. А вот при наличие большого объёма данных сразу видна разница в 1,5 раза.
Я не понял какой ты делаешь вывод и причём тут архитектура. Чем ты объясняешь разницу в размере?
_>>>Зато зависит от архитектуры системы. _>·>Каким образом? К чему эта тупая упёртость? Я ж привёл тебе результат эксперимента — 399 и 419 байт. Проведи эксперимент сам, если не веришь. _>У тебя всё верно, но я говорю об измерение пакетов с двумя ревизиями. ) И от чего по твоему оно зависит, если нет архитектуры системы? )
Мне кажется, что просто разный алгоритм компрессии применён (команды hg выполнялись медленее раза в два), надеюсь это он компрессией занимался.
Да, точно. Почитал доку на hg bundle и обнаружил флажок -t. Если добавить "-t gzip", то размер становится 228763 (напоминаю что у git было 228253). Ы?
_>>>Речь про бэкап сервера, а не про работу с git. ) _>·>Что за "бэкап сервера"? И чем он будет принципиально отличаться в случае git и hg? _>Эмм, тебе не знакомо понятие бэкапа сервера? Не важно инкрементального или нет... _>Отличие у git и hg будет в том, что в случае инкрементального бэкапа хранилище git'a после repack'а придётся копировать всё заново (хотя там может добавилась всего пара ревизий), а в случае hg будет скопировано только реальное изменение (новые ревизии). В случае большой истории в репозитории это может быть очень существенная разница.
Так я и говорю — если ты правда считаешь это проблемой, настрой бэкапы с помощью бандлов.
Я бы вначале подумал над проблемой — а правда ли наивный инкрементальный бэкап файлов активного hg репозитория можно будет использовать для восстановления?
Большой это сколько? Самый большой я видел в своей жизни это 3.2Gb. Фигня для современного железа.
Да и вообще, повторяю — насколько вообще нужны бэкапы для dvcs? Гораздо проще и полезнее сделать репликацию.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, alex_public, Вы писали:
_>>>·>Этого же эффекта можно добиться помещая имя текущей ветки в коммент коммита (можно хук сделать). Но зачем из буханки делать троллейбус? _>>>Можно и так))) Но тогда с этим не смогут работать различные команды (типа heads, pull/push и т.п.). _>·>Команда heads, конечно работать не будет, ибо такой команды в git нет, так как этого бреда с многоголовыми ветками нет. Неслитые ветки в git можно посмотреть, как ни странно, командой branch с ключиком "--no-merged". _>·>А с push/pull что случится-то? _>А причём тут git? ) Я отвечал на твой как бы юмор, что можно было бы сделать реализацию имён веток в Mercurial через добавления этого имени в комментарий ревизии через хук. Так вот я и ответил, что да, теоретически это было бы похоже, но тогда перестали бы работать возможности многих команд Mercurial, умеющих принимать имя ветки в качестве параметра.
Создали сложности и героически с ними борются.
_>Что касается git'a, то его вообще смешно обсуждать в данном контексте, т.к. он банально не умеет создавать ветки без имён. )
Потому что это не имеет смысла.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, netch80, Вы писали:
N>А должно быть "передаём команде ярлык branch1", например. Но не ветку. Но этот твой пример ещё интереснее. Я приводил диаграмму, где этим тегом пометил два коммита в разных ветках. Что команда сделает? Если отфильтрует из всего репо или от указанной точки роста все такие коммиты, то ещё понятно, но какой смысл, если они могут не входить в DAG с общей головой? А если что-то сделать с потенциальной головой, то если их две, какое будет принято решение?
Не, команды по определению имеющие дело с одной ревизией только их и принимают (а не имена ссылок/закладки/теги и т.п.).
_>>Неизменность истории мне нравится больше) N>А при чём тут вообще неизменность истории?
Ну точнее речь не вообще об истории, а о сохранение расклада с именными ветками)
_>>А если причиной развилки будет всего лишь синхронизация изменений с двух разных машин? ) N>Притянул состояние с другой машины — да, явно назвав, иначе несекьюрно — и начал играться. N>А при многих таких нескольких — даже в пределах одного отдела — название ветки начинает играть роль собственно принципиального указания, от кого взято конкретное изменение, потому что понять это по содержанию уже невозможно.
Так а зачем мне изменения другого отдела в чистом виде? ) Мне они не нужны. Мне нужна основная ветка развития, с применёнными к ней изменениями этого отдела (потому как кто кроме них правильнее осуществит слияние их изменений).
N>Безымянная ветка для этого становится случаем ничтожной экономии усилий на частный случай, когда таких источников считанные единицы, они не конфликтуют (до неразличения) по смыслу с любыми локальными изменениями (а программист ещё не устал и способен отличать источники по их виду), используемые средства явно показывают все эти головы и их не настолько много, чтобы не вмещались в интерфейс... возможно, ты и твоя команда способны всё это осиливать, но я предпочту тратить мысленные усилия на что-то более для меня полезное.
Какие мысленные усилия? ) Если предположим (для упрощения объяснения) в данной разработке не нужны долгоживущие отдельные ветки (которые по смыслу создаются, а не для синхронизации отдельных членов команды), то в Mercurial будет просто ровно одна ветка периодически разветвляющаяся (в моменты параллельной разработки членов команды) и тут же сливающаяся в одну.
А что будет в случае в Git? )
_>>Ну тут уже кидали результаты. У меня в принципе похожие — у Mercurial раза в 1,5 меньше получаются пакеты изменений. ) Т.е. где-то так же и сеть загружается при синхронизации. N>При остальных плюшках Git разница не принципиальна, но имеет смысл попинать авторов.
Согласен. ) Я собственно изначально сказал, что оба инструмента полностью удовлетворяют обычного пользователя. А все эти тесты размеров, скоростей и т.п. поднял только после заявления о том, что типа низкоуровневая архитектура git намного совершеннее. )))
Здравствуйте, netch80, Вы писали:
N>>>Ну, если ты знаешь, как провести эти тесты — покажи скрипты и результаты. Не думаю, что они покажут что-то принципиально важное (я лучше бы для сравнения взял результат перегонки чего-то открытого активно разрабатываемого), но просто покрасоваться цифрами — сгодится. _>>Ну тут уже кидали результаты. У меня в принципе похожие — у Mercurial раза в 1,5 меньше получаются пакеты изменений. ) Т.е. где-то так же и сеть загружается при синхронизации.
N>При остальных плюшках Git разница не принципиальна, но имеет смысл попинать авторов.
Чуда не случилось. Разница, как оказалось, в том, что hg использовал bzip2 компрессию, а git — gzip. После смены алгоритма компрессии пакеты стали ровно того же размера.
Странно конечно, что git не использует bzip2, хотя, с учётом того, что этот алгоритм значительно медленнее (раз в 5), может авторы git посчитали это неприемлимым.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
_>>А, всё, я понял что ты нарисовал. Правда не знаю зачем применять для такого именованные ветки (когда нет реальных разветвлений), но если очень хочется, то в mercurial можно без проблем и оно прямо так и будет выглядеть. ) ·>Потому что ветки обычно имеют некий смысл, связанный с процессом разработки, а не с текущей структурой истории. Нужны же ветки для того, чтобы понимать что у нас сейчас release, а что development. А разветвление расхождение веток это текущее состояние истории.
Эм, а какой смысл имеет последовательная группа ревизий с меткой "release"? ) Release — это же обычно некий фиксированный момент времени, а не интервал. Соответственно в репозитории это соответствует одной выделенной ревизии. Обычно её или помечают соответствующим тегом прямо в основной ветке или же создают отдельную ветку с именем release, в которую изредка (как раз в моменты времени релиза) сливают результаты из основной ветки. А то, что показал ты, я никогда не видел и пока не могу представить для чего оно может понадобиться.
_>> И даже меньше команд чем в git понадобится. ))) ·>Покажи, плз. Насколько я знаю в hg без коммита ветку не создать.
Нельзя) Но у тебя же там как раз последовательность фиксаций нарисована. )
·>Мой вопрос в том, что имеется в виду в приведённой тобой документации: «"line of development" is a linear sequence of consecutive changesets». Где в приведённом мной графе истории line of develpment? Что есть head? Что есть branch?
"line of develpment"=="branch" (который реальная ветка, а не атрибут branch name). Ну а head — это последняя ревизия в ветке.
_>>Я вообще то про Mercurial и говорил. ))) ·>Ааа. Понял. Хорошо, как в mercurial отличать мой "experiment" от твоего?
Ну например по автору и по предку (в GUI по положения в дереве).
·>А как тогда такую историю создать? ·>
Я так и не понял, зачем ты хочешь применять ветки там, где нет развилок? )
·>Или, иначе говоря, выразить тот факт, что мы зарелизили всё что надевелопили.
Ну поставь на последнюю ревизию тег "release 2.0" и всё. Или же организуй отдельную ветку с релизами. Я уже писал выше.
_>>
_>>As such, each changeset in Mercurial forms an element of a branch. A changeset thus can be said to "belong to a branch". Per that definition, a branch is simply a linear sequence of changesets.
_>>Ещё требуются пояснения? ) Думаю вполне видно, что никаких намёков на именованные ветки тут нет. ·>Не осиливаю потому что полная мешанина из терминов. Чем тогда бранч отличается от "line of development"?
Ничем и не отличается.
_>>Это не отдельная сущность, а просто название ревизии без потомков. Т.е. этот "термин" можно спокойно и в git применять. ))) ·>Бранч может иметь несколько их. В этом и путаница, которая требует новой сущности. В гите этот термин бессмысленен.
Не может. ) Несколько голов может иметь виртуальная (потому как в реальности её не существует, а есть несколько веток с одинаковым атрибутом "имя") сущность называемая named branch.
_>>Кошмар, кошмар. ))) Нельзя ничего добавлять в систему для удобства пользоваться. Пускай он лучше побольше сам работает, не развалится, да? ))) ·>Конечно нельзя, если можно не добавлять, иначе Оккам бритвочкой полоснёт. Никакого удобства.. путаница только — вроде бы и тег, но какой-то особенный...
Он не особенный, а просто устанавливаемый самой системой (а не пользователем). ))) Автоматика... ) Можешь сам такое сделать хуками в том же git'e.
·>Я не понял какой ты делаешь вывод и причём тут архитектура. Чем ты объясняешь разницу в размере?
Разными алгоритмами и форматами хранилища.
_>>У тебя всё верно, но я говорю об измерение пакетов с двумя ревизиями. ) И от чего по твоему оно зависит, если нет архитектуры системы? ) ·>Мне кажется, что просто разный алгоритм компрессии применён (команды hg выполнялись медленее раза в два), надеюсь это он компрессией занимался. ·>Да, точно. Почитал доку на hg bundle и обнаружил флажок -t. Если добавить "-t gzip", то размер становится 228763 (напоминаю что у git было 228253). Ы?
А можно узнать флажок в git, который позволит добиться результата mercurial? )
), правка более чем на одну ревизию вообще ничем не делается, даже если ты понял, что сотворил дикую чушь (если верить докам) 
Это убойное отличие от Git, который действует по принципу "вы локально можете изменять что угодно, ваши проблемы, но попробуйте теперь заставить других это принять".