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

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

Здесь https://www.mercurial-scm.org/wiki/Branch всё подробно рассказано. Почему-то пользователи git путают "branch name" (всего лишь атрибут ревизии) и реальные ветки (а вот их в упор не видят, хотя они и являются основным инструментом). И в результате получают глупости типа описанных в последнем предложение по моей ссылке. )))

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

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

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

Ну так правильно, heads то показывает не все существующие ветки в репозитории, а только некое подмножество — не слитые. А heads <branchname> показывает ещё более мелкое подмножество — помеченные определённым именем.

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

_>>Ну так про время собственно никто ничего и не говорил. ) Но если уж и говорить, то ты же понимаешь, что такие изменения на практике никогда не встречаются (это только для теста было), так что и подобных задержек тоже.
·>Так и незапакованные гит-репозитории на практике никогда не встречаются.
·>А если не учитывать время, то hg тупо слил по размеру в 6 раз!

Ну давай объясни мне в какой момент произойдёт на практике это чудесная автоматическая перепаковка. Вот завёл я чистый репозиторий. Кинул в него несколько больших (для удобства теста) текстовых файлов — ничего нет. Добавил несколько ревизий — всё равно ничего нет (а размер хранилища уже за мегабайт вылезает, в то время как у mercurial намного меньше). Так когда же? )

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

Ага, ага http://draketo.de/proj/hg-vs-git-server/test-results.html. Или это слишком сложно и детально? ) Тогда рекомендую глянуть на такие http://stackoverflow.com/questions/6969385/why-is-my-git-repository-so-much-larger-than-mercurial-version вопросы, периодически возникающие на SO и т.п. местах.

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

Враньё. ) Ну или же ты с ними просто не работаешь (склонировал с каких-то серверов и всё).

_>>Ну так практика то говорит что хуже. ))) Проверь сам. ) Только по честному, без предварительных ручных repack'ов репозитория. )))
·>Опиши эксперимент, а лучше проведи сам. Разницу в 10-20% не учитывать, ибо не принципиальна.

Берём текстовый файл на мегабайт (чтобы ясно была разница, а то там всякие накладные расходы и т.п.). Кидаем в чистый репозиторий. Фиксируем ревизию. Меняем одну строчку в файле, снова фиксируем. Делаем пакет (bundle) из одной последней ревизии и смотрим размер файла (число1, должно быть очень маленькое), делаем пакет из двух последних ревизий (по сути будет весь репозиторий) и смотрим размер файла (число2, должно быть большое). Выполняем эту последовательность и для mercurial и для git, а потом сравниваем в начале две версии числа1, а потом две версии числа 2.

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

Пакованным они будут до добавления новых ревизий, т.е. очень не долго. )

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

Ну для начала с "много места" мы ещё и не разобрались. И кстати говоря у всех подходов есть свои недостатки. Даже если взять за основу идею с repack'ом, то помимо проблем с расписанием данной работы, данная техника к примеру блокирует возможность инкрементальных бэкапов хранилища.