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

_>>Хы, они не многоголовые)
·>А это о чём тогда? http://stackoverflow.com/questions/6927733/mercurial-how-to-deal-with-one-branch-that-has-two-heads

Да просто очередной не читавший документацию и не смогший понять, что у него теперь просто две ветки.

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

А причём тут централизованные системы? ) Там как раз ничего подобного нет. )

_>> Но при этом это всё полноценные ветки со всеми механизмами работы с ними. )
_>>И кстати говоря это один из самых удобных инструментов работы.
·>Ага, чуть что — создавайте клоны.

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

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

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

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

Это общеизвестный факт (если конечно же не делать периодических ручных repack'ов).

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

Уууу)

У себя на диске (у тебя же есть свои проекты в git не так ли?) проверь для начала. )))

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

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

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

Ну так практика то говорит что хуже. ))) Проверь сам. ) Только по честному, без предварительных ручных repack'ов репозитория. )))

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

С чего ты взял, что он стандартный? ) Насколько часто лично ты делаешь repack своих личных проектов? )

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

Ага, вот и реальность проявляется...

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

P.S. На самом деле лично мне вообще то совсем не принципиален размер хранилища, просто этот вопрос всплыл в контексте сравнения эффективности внутренней архитектуры этих двух систем.