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

_>>>Хы, они не многоголовые)
_>·>А это о чём тогда? http://stackoverflow.com/questions/6927733/mercurial-how-to-deal-with-one-branch-that-has-two-heads
_>Да просто очередной не читавший документацию и не смогший понять, что у него теперь просто две ветки.
Покажи документацию, которую читаешь ты.

_>>>Надо просто понимать, что в mercurial есть как именованные ветки, так и анонимные (такого в git насколько я помню вообще нет?). )
_>·>Деструктивного влияния централизованных VCS на DVCS? Нет, конечно.
_>А причём тут централизованные системы? ) Там как раз ничего подобного нет. )
hg пытается сидеть на двух стульях, вроде как dvcs, а имена веток — глобальные, как в cvcs. А ещё эти приколы с номерами ревизий...

_>Эм, какие клоны? ) Ты вообще о чём? ) Я говорил об удобстве работы на базе использования анонимных веток в mercurial (которые автоматически создаются, когда обнаруживается двое или более ревизий потомком у одной базовой). Причём это удобно даже если говорить не о синхронизации нескольких разработчиков (там это вообще идеально полезно), а о просто одиночной работе — неудобно придумывать название и создавать руками отдельную ветку ради маленького одиночного эксперимента с кодом (довольно распространённый сценарий).
Скажи... Ты читал документацию на "hg heads"? Что показывает эта команда в формате "hg heads <branchname>"? В каком словаре слово "head" означает "анонимная ветка"?

_>>>Нормально всё померил) Только вот где "плохо всё с hg"? Всё в точности, как я и говорил. Даже при наличие всего одного набора данных в хранилище mercurial занял 30 мегов, а git 32, как я собственно и говорил.
_>·>За почти вдвое большее время работы hg мог бы постараться сжать получше, чем на 10%, которые в пределах погрешности измерения.
_>Ну так про время собственно никто ничего и не говорил. ) Но если уж и говорить, то ты же понимаешь, что такие изменения на практике никогда не встречаются (это только для теста было), так что и подобных задержек тоже.
Так и незапакованные гит-репозитории на практике никогда не встречаются.
А если не учитывать время, то hg тупо слил по размеру в 6 раз!

_>>>Причём при дальнейшей работе эта разница ещё увеличится.
_>·>Враньё. Или факты в студию.
_>Это общеизвестный факт (если конечно же не делать периодических ручных repack'ов).
Нет, типичное враньё.

_>>>Если же ты намекаешь на размер после repack (5,8 мегов), который ты забавно назвал "size final", то мы вроде как уже обсудили, что к реальности оно никакого отношения не имеет.
_>·>Именно это и будет реальный размер в любом долгоживущем или свежесклонированном репозитории.
_>Уууу)
_>У себя на диске (у тебя же есть свои проекты в git не так ли?) проверь для начала. )))
Проверял, неоднократно. Все мои репозитории запакованы.

_>>>·>А вообще, какого файла?.. Если у тебя полная ревизия, то да, будет полный снапшот, если это diff, будет diff.
_>>>Не важно что) Главное чтобы одинаковое было (по смыслу) и в mercurial и в git.
_>·>За счёт чего ты ожидаешь какую-то существенную разницу? Я ожидаю разницу в пользу git, т.к. он имеет более подходящие структуры данных.
_>Мне не важно за счёт чего.
Пока это похоже на священную веру — фактов нет, тестов нет, почему — не важно, но свято веришь.

_>Я просто проверял и знаю ответ. Но предлагаю тебе убедиться самому. )
Я давно уже убедился.

_>>>·>Как это зависит от vcs?
_>>>Разные форматы этих файлов и разные алгоритмы сжатия. Собственно так же как и в самом хранилище. Легко увидеть где оптимальнее... )))
_>·>Ну? В git лучше форматы и алгоритмы. Я не понимаю зачем ты доказываешь преимущества git, я и не спорю с этим.
_>Ну так практика то говорит что хуже. ))) Проверь сам. ) Только по честному, без предварительных ручных repack'ов репозитория. )))
Опиши эксперимент, а лучше проведи сам. Разницу в 10-20% не учитывать, ибо не принципиальна.

_>>>Как же это наоборот, если твои же собственные измерения подтвердили мои слова? ) Или ты всё же настаиваешь на том, что стоит учитывать в оценке размер после repack? )))
_>·>Конечно, я же учитываю стандартный реальный юзкейс, а не мысленные эксперименты, основанные на священной вере.
_>С чего ты взял, что он стандартный? ) Насколько часто лично ты делаешь repack своих личных проектов? )
Никогда не делаю. Ещё раз повторяю — git сам repack делает, если ему явно не запретить.

_>>>Кстати, интересно было бы сделать опрос на форуме, среди активных пользователей git. Сколько раз они делали repack для своих проектов? Что-то я подозреваю, что многие даже не в курсе про подобную функцию. )))
_>·>Да никто его вручную обычно не делает, он сам выполняется периодически, когда становится слишком много loose objects.
_>Ага, вот и реальность проявляется...

_>Давай всё же подведём какой-то итог данному подразделу нашей дискуссий. Моё утверждение было такое: хранилище mercurial занимает меньше места чем хранилище git без постоянных ручных repack'ов последнего, а этим никто в реальности не занимается. Поясни с какой его частью (первой или второй) ты всё же не согласен.
"постоянных ручных repack'ов последнего, а этим никто в реальности не занимается" — с этим согласен, никто вручную repack не делает в реальности.
"хранилище mercurial занимает меньше места" — не согласен, т.к. надо рассматривать пакованный репо, ибо в реальности репы пакованные.

_>P.S. На самом деле лично мне вообще то совсем не принципиален размер хранилища, просто этот вопрос всплыл в контексте сравнения эффективности внутренней архитектуры этих двух систем.
"Меньше места" не единственный эффект более продуманной архитектуры. Это так же даёт перформанс, простоту алгоритмов.