Здравствуйте, ·, Вы писали:
_>>Не, я не про старые DVCS. Там ниже было высказывание, что к CVS и SVN ближе Git, а не Mercurial. ) ·>Там вроде про ветки. Ветки — да, в hg это нечто уникальное, неповторимое понимание, попытка натянуть сову на глобус. Где ещё есть многоголовые ветки?
Хы, они не многоголовые) Надо просто понимать, что в mercurial есть как именованные ветки, так и анонимные (такого в git насколько я помню вообще нет?). ) Но при этом это всё полноценные ветки со всеми механизмами работы с ними. )
И кстати говоря это один из самых удобных инструментов работы.
_>>ОК, давай возьмём просто любой большой проект и кинем его в чистый репозиторий) Причём это ещё будет максимально лояльным для Git тестом, т.к. у него размер существенно растёт именно с числом изменений. ·>Дело было вечером, делать было нечего. Я взял openssl-1.0.1r.tar.gz, 4.4мб, распаковал 44мб исходников, 2183 файлов, 130 каталогов... Что-то плохо всё с hg: ·>... ·>Время в секундах, размер в мегабайтах. hg 3.4, git 2.0.3, ubuntu, linux 4.2.0-23. ·>Очень интересно — размер repacked git репо сравним с tar.gz тех же данных. ·>Проведи такой же эксперимент — интересно будут такие же результаты или я что-то не так померил...
Нормально всё померил) Только вот где "плохо всё с hg"? Всё в точности, как я и говорил. Даже при наличие всего одного набора данных в хранилище mercurial занял 30 мегов, а git 32, как я собственно и говорил. Причём при дальнейшей работе эта разница ещё увеличится.
Если же ты намекаешь на размер после repack (5,8 мегов), который ты забавно назвал "size final", то мы вроде как уже обсудили, что к реальности оно никакого отношения не имеет.
_>>Не, я не про это. Я про размер получаемого файла (в котором по сути содержится весь репозиторий). Какой он будет у Mercurial, а какой у Git. Тут же утверждали, что низкоуровневая архитектура у Git более продумана и позволяет большее сжатие и т.п. А на практике... ·>... так и получается. ·>А вообще, какого файла?.. Если у тебя полная ревизия, то да, будет полный снапшот, если это diff, будет diff.
Не важно что) Главное чтобы одинаковое было (по смыслу) и в mercurial и в git.
·>Как это зависит от vcs?
Разные форматы этих файлов и разные алгоритмы сжатия. Собственно так же как и в самом хранилище. Легко увидеть где оптимальнее... )))
_>>·>Будет, но не долго, до первого же repack. _>>Угу и потом ещё пару изменений продержится на минимуме, а потом снова... ))) ·>Может в каких-то ситуациях так и может быть, но обычно с точностью до наоборот.
Как же это наоборот, если твои же собственные измерения подтвердили мои слова? ) Или ты всё же настаиваешь на том, что стоит учитывать в оценке размер после repack? )))
Кстати, интересно было бы сделать опрос на форуме, среди активных пользователей git. Сколько раз они делали repack для своих проектов? Что-то я подозреваю, что многие даже не в курсе про подобную функцию. )))
Здравствуйте, ·, Вы писали:
·>Здравствуйте, Mazenrab, Вы писали:
AK>>>я почему интересуюсь, для меня, как C# программера — это базовая операция — переименование класса (class per file). M>>На днях натыкался — есть такая проблема. ·>Да нет такой проблемы, открой для себя "git log -M" или ещё круче — "git blame -C", который может найти, например, перемещённый метод из одного файла в другой (такого в hg вроде нет).
Спасибо, попробую при случае. Но я вообще стараюсь пользоваться встроенным в студию инструментарием полагая что так сложнее выстрелить себе в ногу.
Здравствуйте, alex_public, Вы писали:
_>>>Не, я не про старые DVCS. Там ниже было высказывание, что к CVS и SVN ближе Git, а не Mercurial. ) _>·>Там вроде про ветки. Ветки — да, в hg это нечто уникальное, неповторимое понимание, попытка натянуть сову на глобус. Где ещё есть многоголовые ветки? _>Хы, они не многоголовые)
А это о чём тогда? http://stackoverflow.com/questions/6927733/mercurial-how-to-deal-with-one-branch-that-has-two-heads
_>Надо просто понимать, что в mercurial есть как именованные ветки, так и анонимные (такого в git насколько я помню вообще нет?). )
Деструктивного влияния централизованных VCS на DVCS? Нет, конечно.
_> Но при этом это всё полноценные ветки со всеми механизмами работы с ними. ) _>И кстати говоря это один из самых удобных инструментов работы.
Ага, чуть что — создавайте клоны.
_>·>Очень интересно — размер repacked git репо сравним с tar.gz тех же данных. _>·>Проведи такой же эксперимент — интересно будут такие же результаты или я что-то не так померил... _>Нормально всё померил) Только вот где "плохо всё с hg"? Всё в точности, как я и говорил. Даже при наличие всего одного набора данных в хранилище mercurial занял 30 мегов, а git 32, как я собственно и говорил.
За почти вдвое большее время работы hg мог бы постараться сжать получше, чем на 10%, которые в пределах погрешности измерения.
_>Причём при дальнейшей работе эта разница ещё увеличится.
Враньё. Или факты в студию.
_>Если же ты намекаешь на размер после repack (5,8 мегов), который ты забавно назвал "size final", то мы вроде как уже обсудили, что к реальности оно никакого отношения не имеет.
Именно это и будет реальный размер в любом долгоживущем или свежесклонированном репозитории.
_>·>... так и получается. _>·>А вообще, какого файла?.. Если у тебя полная ревизия, то да, будет полный снапшот, если это diff, будет diff. _>Не важно что) Главное чтобы одинаковое было (по смыслу) и в mercurial и в git.
За счёт чего ты ожидаешь какую-то существенную разницу? Я ожидаю разницу в пользу git, т.к. он имеет более подходящие структуры данных.
_>·>Как это зависит от vcs? _>Разные форматы этих файлов и разные алгоритмы сжатия. Собственно так же как и в самом хранилище. Легко увидеть где оптимальнее... )))
Ну? В git лучше форматы и алгоритмы. Я не понимаю зачем ты доказываешь преимущества git, я и не спорю с этим.
_>>>Угу и потом ещё пару изменений продержится на минимуме, а потом снова... ))) _>·>Может в каких-то ситуациях так и может быть, но обычно с точностью до наоборот. _>Как же это наоборот, если твои же собственные измерения подтвердили мои слова? ) Или ты всё же настаиваешь на том, что стоит учитывать в оценке размер после repack? )))
Конечно, я же учитываю стандартный реальный юзкейс, а не мысленные эксперименты, основанные на священной вере.
_>Кстати, интересно было бы сделать опрос на форуме, среди активных пользователей git. Сколько раз они делали repack для своих проектов? Что-то я подозреваю, что многие даже не в курсе про подобную функцию. )))
Да никто его вручную обычно не делает, он сам выполняется периодически, когда становится слишком много loose objects.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Да просто очередной не читавший документацию и не смогший понять, что у него теперь просто две ветки.
_>>Надо просто понимать, что в 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. На самом деле лично мне вообще то совсем не принципиален размер хранилища, просто этот вопрос всплыл в контексте сравнения эффективности внутренней архитектуры этих двух систем.
Здравствуйте, 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. На самом деле лично мне вообще то совсем не принципиален размер хранилища, просто этот вопрос всплыл в контексте сравнения эффективности внутренней архитектуры этих двух систем.
"Меньше места" не единственный эффект более продуманной архитектуры. Это так же даёт перформанс, простоту алгоритмов.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
_>>Да просто очередной не читавший документацию и не смогший понять, что у него теперь просто две ветки. ·>Покажи документацию, которую читаешь ты.
Здесь 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'ов). ·>Нет, типичное враньё.
Враньё. ) Ну или же ты с ними просто не работаешь (склонировал с каких-то серверов и всё).
_>>Ну так практика то говорит что хуже. ))) Проверь сам. ) Только по честному, без предварительных ручных repack'ов репозитория. ))) ·>Опиши эксперимент, а лучше проведи сам. Разницу в 10-20% не учитывать, ибо не принципиальна.
Берём текстовый файл на мегабайт (чтобы ясно была разница, а то там всякие накладные расходы и т.п.). Кидаем в чистый репозиторий. Фиксируем ревизию. Меняем одну строчку в файле, снова фиксируем. Делаем пакет (bundle) из одной последней ревизии и смотрим размер файла (число1, должно быть очень маленькое), делаем пакет из двух последних ревизий (по сути будет весь репозиторий) и смотрим размер файла (число2, должно быть большое). Выполняем эту последовательность и для mercurial и для git, а потом сравниваем в начале две версии числа1, а потом две версии числа 2.
_>>Давай всё же подведём какой-то итог данному подразделу нашей дискуссий. Моё утверждение было такое: хранилище mercurial занимает меньше места чем хранилище git без постоянных ручных repack'ов последнего, а этим никто в реальности не занимается. Поясни с какой его частью (первой или второй) ты всё же не согласен. ·>"постоянных ручных repack'ов последнего, а этим никто в реальности не занимается" — с этим согласен, никто вручную repack не делает в реальности. ·>"хранилище mercurial занимает меньше места" — не согласен, т.к. надо рассматривать пакованный репо, ибо в реальности репы пакованные.
Пакованным они будут до добавления новых ревизий, т.е. очень не долго. )
_>>P.S. На самом деле лично мне вообще то совсем не принципиален размер хранилища, просто этот вопрос всплыл в контексте сравнения эффективности внутренней архитектуры этих двух систем. ·>"Меньше места" не единственный эффект более продуманной архитектуры. Это так же даёт перформанс, простоту алгоритмов.
Ну для начала с "много места" мы ещё и не разобрались. И кстати говоря у всех подходов есть свои недостатки. Даже если взять за основу идею с repack'ом, то помимо проблем с расписанием данной работы, данная техника к примеру блокирует возможность инкрементальных бэкапов хранилища.
"The term branch is sometimes used for slightly different concepts. This may be confusing for new users of Mercurial." Золотые слова. Вот пока оно будет использоваться, и не под "slightly" разные концепции, а под существенно разные, будет постоянный бардак между ветками, которые специализированные теги коммитов, ветками, которые пучки веток, ветки, которые ещё не слитые ветки (как в твоём ниже про heads) и так далее.
Если этот бардак убрать и нормализовать терминологию, уровень проблем с Hg резко уменьшится, а пользователей таки добавится. Может, и я попробую его в работе хотя нет, для этого нужен ещё и аналог гитового index с полноценной поддержкой, и interactive rebase с его возможностями по расщеплению, слиянию и перестановке коммитов, модификации батчем. Вот после этого для меня они будут близки к эквивалентам.
_>Почему-то пользователи git путают "branch name" (всего лишь атрибут ревизии) и реальные ветки (а вот их в упор не видят, хотя они и являются основным инструментом). И в результате получают глупости типа описанных в последнем предложение по моей ссылке. )))
Не "пользователи git", не надо натяжек, а все, кто не пришёл к этому "дети, это невозможно понять, но это надо запомнить". Я пытался разобраться с Hg, ещё не зная Git, запутался в этом бардаке, плюнул и забыл. Зато потом с Git было всё просто и понятно.
_>Ну так правильно, heads то показывает не все существующие ветки в репозитории, а только некое подмножество — не слитые. А heads <branchname> показывает ещё более мелкое подмножество — помеченные определённым именем.
Во-во. Тут не ходи, тут рыбу заворачивали...
_>Так а может ты пояснишь, какой аналог анонимных веток у нас в git? ) Т.е. что делать при нескольких параллельных изменения относительно одной родительской ревизии, обязательно заводить отдельную именованную ветку? )
Да. Это чуть больше работы, но это небольшая цена за внятность концепции.
_>Ну давай объясни мне в какой момент произойдёт на практике это чудесная автоматическая перепаковка. Вот завёл я чистый репозиторий. Кинул в него несколько больших (для удобства теста) текстовых файлов — ничего нет. Добавил несколько ревизий — всё равно ничего нет (а размер хранилища уже за мегабайт вылезает, в то время как у mercurial намного меньше). Так когда же? )
`git help gc` рассказывает это. Мегабайт не тот размер, о котором считается осмысленным заботиться (хотя оно считает не по объёму, а по количеству объектов и паков).
С другой стороны, ряд источников говорит "выполняйте gc регулярно в на другой подходящий момент, например, при уходе на обеденный перерыв".
_>Ага, ага http://draketo.de/proj/hg-vs-git-server/test-results.html. Или это слишком сложно и детально? )
Это люди фатально не умеют рисовать графики — за такие рисунки отправлять в третий класс на пересдачу основ. Разбираться в однопиксельных пометках не стал, пошёл сразу к выводам. Пишут, что репо Git в среднем больше, если не начинается много веток, тогда оно меньше. Учитывая типичный стиль работы над действительно большим и серьёзным проектом, где обычно веток много (подготовки релизов, конкретные релизы, трейны апдейтов, параллельные трейны с перетеканием отлаженных фич), это важнее, чем на просто линейной истории.
_> Тогда рекомендую глянуть на такие http://stackoverflow.com/questions/6969385/why-is-my-git-repository-so-much-larger-than-mercurial-version вопросы, периодически возникающие на SO и т.п. местах.
А тут проскакивает, что преимущество Hg в сжатии диффов бинарников. Опять же сомнительное удовольствие (я в рамках благостных пожеланий "а хорошо бы такое увидеть", конечно, хочу, но в реальной жизни как-то не сталкивался — это что ж за бинарники такие, что между версиями можно получить компактный diff?)
_>Берём текстовый файл на мегабайт (чтобы ясно была разница, а то там всякие накладные расходы и т.п.). Кидаем в чистый репозиторий. Фиксируем ревизию. Меняем одну строчку в файле, снова фиксируем. Делаем пакет (bundle) из одной последней ревизии
Что такое bundle?
_>·>"хранилище mercurial занимает меньше места" — не согласен, т.к. надо рассматривать пакованный репо, ибо в реальности репы пакованные. _>Пакованным они будут до добавления новых ревизий, т.е. очень не долго. )
Они останутся до перепаковки. Новые ревизии добавят новые непакованные объекты, факт. Но старые трогать никто не будет, пока не придёт gc, repack или аналог.
_>Ну для начала с "много места" мы ещё и не разобрались. И кстати говоря у всех подходов есть свои недостатки. Даже если взять за основу идею с repack'ом, то помимо проблем с расписанием данной работы, данная техника к примеру блокирует возможность инкрементальных бэкапов хранилища.
Именно в виде пофайловой копии .git/ — да. Но смысл такого копирования возникает только на репо, которое не может бэкапиться через банальный pull с запретом форсирований операций. А такие, как правило, отражают какие-то спецвиды возни вроде состояний, которые регулярно проходят через upstream rebase — это, например, ветки фида новых коммитов на рассмотрение в корневые репо Linux kernel. Формально проблема есть, практически же её важность крошечна.
Здравствуйте, alex_public, Вы писали:
N>>Разница в том, что в Git при ветках, которые ветки, правила просты и логичны. В Hg разрыв между нормальным пониманием ветки и тем, что там называется этим словом, приводит к бардаку. Если переименуете на другой термин, который не конфликтует с языком, часть жалоб уйдёт. _>Ещё раз поясняю: в mercurial как раз самые нормальные ветки, просто ты не разобрался.
Что "не разобрался" — согласен в варианте "в этом проще запутаться, чем разобраться".
Что "самые нормальные" — ты этого не докажешь.
Skip дальше кусок — я понял, что у тебя в пределах ветки-1 (именованной базы роста) несколько веток-2 (просто направлений роста истории), которые ты потом сводишь, называя их своими идентификаторами. На самом деле в Git такое возможно, но если ты не дал имя такой голове, будешь знать только её id и её может удалить GC. Если ты гарантированно не допустишь GC, то можно так работать (rebase внутри себя так и делают). Только нафиг надо так корёжиться.
_>>> Кстати, аналогичного можно добиться и проще (как раз более практичный вариант) — фиксация своих изменений несколькими разработчиками в одну и ту же ветку, с последующей синхронизацией. N>>Пофиг, как ветка называется у каждого конкретного разработчика, важно, в какую в общем репо они вливают (и с какой мержатся). _>Зачем нам лишняя сущность типа третьего репозитория? )
Он может быть и вторым, и первым. Я нигде не утверждал, что общее репо может быть отдельным, это ты уже домыслил по непониманию.
_>Кстати, в режиме по умолчанию Mercurial синхронизирует сразу все ветки в репозиторию. Это так, к сведению. )
У Git такое умолчание _намеренно_ устранили в районе 2.2, теперь умолчание — одна ветка к одной ветке. Это так, к сведению
_>>>В Mercurial всё будет крайне удобно и это собственно один из нормальных сценариев работы. N>>В Git всё будет "крайне удобно", но после того, как ты наконец объяснишь, чего ты именно хочешь и зачем. _>Ну сейчас увидим как удобно будет. )
Удобства не увидел. Чтобы оно появилось, нужно, чтобы был смысл в параллельном развитии голов от одного разработчика и при этом переключаться между ними по идентификаторам, намеренно отказываясь от имён. Это уже религиозные заморочки, мне такое сложно понять.
_>>>Ужасы какие) Как раз для таких дел и создают отдельные ветки (отладочная, релизная и т.п.). N>>При чём тут вообще какие-то отдельные ветки? Описанные проблемы и методы решения не зависят от того, это develop, old stable или что-то ещё. _>Ну если тебе требуется наличие в репозитории двух версий одного кода, одну с отладочной печатью, а другую без, то это как раз удобнее делать через ветки. )
Вот даже в пределах этой темы можно уже собирать коллекцию того, какие интересные вещи ты домысливаешь за меня, не имея для этого никаких данных. Откуда вдруг идея про версии кода _в репозитории_? Отладочная печать вставлена только в рабочей копии. Если бы она была в репозитории (например, для отправки на CI и получения лога в условиях, близких к целевой машине), она была бы создана целевым коммитом (а затем выпилена revert'ом, или перенесено в общую ветку всё, кроме неё).
Здравствуйте, alex_public, Вы писали:
_>Хы, в 1997 самый громкий шум в мире линуха был неслышным шорохом на уровне остальной IT индустрии. )))
Менее массовые DVCS отрабатывались именно там, и концепции формировались именно там. И я не про 1997, а про 2000-2004.
В IT чаще всего так и получается — что-то возникшее в очень узкой нише вдруг получает развитие со всей его спецификой (вспомним x86 для PC).
_>Не, ветки из git'a, которые не сохраняются, а просто являются указателями на последние ревизии — они похожи на bookmarks. А как раз в самом Mercurial нормальные ветки. Просто ты не понял что сам сделал в системе и решил из этого какие-то выводы извлечь. )))
Я как раз всё понял. Что я простыми не специально извратными движениями породил "ветку", разорванную между ветками. И что первое, чему нужно учить пользователя Hg — это трём (минимум) смыслам слова "ветка" и как их не надо путать.
_>>>А вот тут http://rsdn.ru/forum/flame.comp/6335381.1
высказывается (и не мною) прямо противоположное мнение. ))) N>>Я не вижу там никакого противоречия тому, что я говорю. Разъясни подробнее, если видишь. _>Вроде как там ясно написано, что старым системам (cvs, svn и т.п.) ближе mercurial, а git наоборот отбросил все традиции и поэтому непривычен. Это полностью противоречит твой фразе о том, что к старым системам ближе git, а mercurial забил на традиции.
Ну, там сказано немного иначе. Но если ты делаешь такие выводы, то тут я с коллегой "·" не согласен; и я не принимаю никакого упрёка просто из того, что кто-то ещё говорит иначе. Если ты хотел припугнуть меня чужим мнением, то это просто смешно в своей наивности.
Здравствуйте, alex_public, Вы писали:
_>>>Да просто очередной не читавший документацию и не смогший понять, что у него теперь просто две ветки. _>·>Покажи документацию, которую читаешь ты. _>Здесь https://www.mercurial-scm.org/wiki/Branch всё подробно рассказано. Почему-то пользователи git путают "branch name" (всего лишь атрибут ревизии) и реальные ветки (а вот их в упор не видят, хотя они и являются основным инструментом).
Может я буквы читать разучился, но покажи в какой позиции в строке "you must first pull the head of that development line " находится слово "branch"?
В документации branch — это такой монстр, имя которого хранится в атрибуте, у которого есть множество heads. А ещё есть development line, related repositories. А ещё, оказывается, hg мержит не branches, а lines of development.
Столько ненужной и лишней терминологии просто из-за кривого дизайна системы.
_>И в результате получают глупости типа описанных в последнем предложение по моей ссылке. )))
Которой ссылке? Я правильно понял, ты имеешь в виду что в официальной документации hg написана глупость?
_>>>А причём тут централизованные системы? ) Там как раз ничего подобного нет. ) _>·>hg пытается сидеть на двух стульях, вроде как dvcs, а имена веток — глобальные, как в cvcs. А ещё эти приколы с номерами ревизий... _>А расскажи, чем по твоему неудобны глобальные имена веток? )
Тем что это противоречит распределённости. Лишняя сущность, которая нужна далеко не всегда. Что плохого в том, если два разработчика создадут ветки "experiment", а потом захотят обменяться?
_>Про номера ревизий не понял в чём проблема, это всего лишь локальные хоткеи для удобства (если не хочешь, можешь вообще не обращать на них внимание) адресации.
Ещё одна ненужная нашлёпка сбоку, унаследованная от cvcs.
_>>>Эм, какие клоны? ) Ты вообще о чём? ) Я говорил об удобстве работы на базе использования анонимных веток в mercurial (которые автоматически создаются, когда обнаруживается двое или более ревизий потомком у одной базовой). Причём это удобно даже если говорить не о синхронизации нескольких разработчиков (там это вообще идеально полезно), а о просто одиночной работе — неудобно придумывать название и создавать руками отдельную ветку ради маленького одиночного эксперимента с кодом (довольно распространённый сценарий). _>·>Скажи... Ты читал документацию на "hg heads"? Что показывает эта команда в формате "hg heads <branchname>"? В каком словаре слово "head" означает "анонимная ветка"? _>Ну так правильно, heads то показывает не все существующие ветки в репозитории, а только некое подмножество — не слитые. А heads <branchname> показывает ещё более мелкое подмножество — помеченные определённым именем.
Объясни, каким словарём ты пользуешься, что словосочетание "branch heads" ты переводишь как "ветки"? Или в документаци, как всегда, глупость написана?
_>Так а может ты пояснишь, какой аналог анонимных веток у нас в git? ) Т.е. что делать при нескольких параллельных изменения относительно одной родительской ревизии, обязательно заводить отдельную именованную ветку? )
А если не обязательно параллельных?
В общем да, можно и ветку завести — ибо это ничего не стоит и никаких сложностей не создаёт. Это же не hg, где если заведёшь ветку, то это "навсегда". Собственно эта "фича" hg продиктована необходимостью — ветку завести не всегда возможно, вот и пришлось придумать новую сущность — головы.
Ещё можно просто по sha1 обращаться. Можно reflog полистать, можно в stash закинуть. Вариантов куча.
_>·>Так и незапакованные гит-репозитории на практике никогда не встречаются. _>·>А если не учитывать время, то hg тупо слил по размеру в 6 раз! _>Ну давай объясни мне в какой момент произойдёт на практике это чудесная автоматическая перепаковка. Вот завёл я чистый репозиторий. Кинул в него несколько больших (для удобства теста) текстовых файлов — ничего нет. Добавил несколько ревизий — всё равно ничего нет (а размер хранилища уже за мегабайт вылезает, в то время как у mercurial намного меньше). Так когда же? )
Если хочешь разобраться досконально, читай хелп на "git gc", флажок --auto. Там точно указаны правила. Используются несколько имперически подобранных параметров, чтобы в более менее стандартных ситуациях давать хороший результат, если что — можно подкрутить для особых случаев. Вроде очевидно, что "несколько мегабайт" это не то, о чём стоит волноваться.
_>>>·>Враньё. Или факты в студию. _>>>Это общеизвестный факт (если конечно же не делать периодических ручных 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.
kan@altegol:~/tmp/experiment/bundle/git$ ls -l
total 1424
-rw-rw-r-- 1 kan kan 228253 Feb 6 13:25 1.bundle
-rw-rw-r-- 1 kan kan 419 Feb 6 13:26 2.bundle
-rw-rw-r-- 1 kan kan 1198368 Feb 6 13:18 file
kan@altegol:~/tmp/experiment/bundle/hg$ ls -l
total 1356
-rw-rw-r-- 1 kan kan 157286 Feb 6 13:41 1.bundle
-rw-rw-r-- 1 kan kan 399 Feb 6 13:42 2.bundle
-rw-rw-r-- 1 kan kan 1198368 Feb 6 13:39 file
Разница есть, конечно, но не принципиальна... Вообще не понимаю причём тут бандлы, они от структуры репозитория не зависят.
_>>>Давай всё же подведём какой-то итог данному подразделу нашей дискуссий. Моё утверждение было такое: хранилище mercurial занимает меньше места чем хранилище git без постоянных ручных repack'ов последнего, а этим никто в реальности не занимается. Поясни с какой его частью (первой или второй) ты всё же не согласен. _>·>"постоянных ручных repack'ов последнего, а этим никто в реальности не занимается" — с этим согласен, никто вручную repack не делает в реальности. _>·>"хранилище mercurial занимает меньше места" — не согласен, т.к. надо рассматривать пакованный репо, ибо в реальности репы пакованные. _>Пакованным они будут до добавления новых ревизий, т.е. очень не долго. )
Нет, конечно. Только новые ревизии будут не пакованными, до очередного gc.
_>>>P.S. На самом деле лично мне вообще то совсем не принципиален размер хранилища, просто этот вопрос всплыл в контексте сравнения эффективности внутренней архитектуры этих двух систем. _>·>"Меньше места" не единственный эффект более продуманной архитектуры. Это так же даёт перформанс, простоту алгоритмов. _>Ну для начала с "много места" мы ещё и не разобрались. И кстати говоря у всех подходов есть свои недостатки. Даже если взять за основу идею с repack'ом, то помимо проблем с расписанием данной работы, данная техника к примеру блокирует возможность инкрементальных бэкапов хранилища.
Не блокирует. Просто иногда после repack придётся новые паки бэкапить, старые удалять, вот и всё. А вообще не проще ли --mirror использовать или тупо rsync?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, netch80, Вы писали:
_>>Здесь https://www.mercurial-scm.org/wiki/Branch всё подробно рассказано. N>"The term branch is sometimes used for slightly different concepts. This may be confusing for new users of Mercurial." Золотые слова. Вот пока оно будет использоваться, и не под "slightly" разные концепции, а под существенно разные, будет постоянный бардак между ветками, которые специализированные теги коммитов, ветками, которые пучки веток, ветки, которые ещё не слитые ветки (как в твоём ниже про heads) и так далее. N>Если этот бардак убрать и нормализовать терминологию, уровень проблем с Hg резко уменьшится, а пользователей таки добавится. Может, и я попробую его в работе хотя нет, для этого нужен ещё и аналог гитового index с полноценной поддержкой, и interactive rebase с его возможностями по расщеплению, слиянию и перестановке коммитов, модификации батчем. Вот после этого для меня они будут близки к эквивалентам.
Давай я сформулирую кратко всё что касается веток в Mercurial. И так, ветка в Mercurial — это последовательность ревизий связанных родительскими отношениями. Соответственно если в системе каким-то образом (есть разные варианты) появляется развилка (несколько ревизий с одной родительской ревизией), то это означает создание (автоматическое!) новой ветки. Это всё, что касается веток! Больше ничего в базовой архитектуре нет. И это настолько просто, что я не понимаю где тут можно в чём-то запутаться. И оно намного удобнее всяких git'ов, в которых без дополнительного набора команд работы с именованными ветками нельзя сделать ничего полезного.
Отдельно в Mercurial существует ещё несколько понятий, которые ты возможно путаешь:
1. Имена веток — это просто неизменяемый атрибут ревизий с особым свойством, он автоматически передаётся всем наследникам данной ревизии (если руками не указано иного).
2. Закладки — просто символические указатели (опциональные) на последнюю (автоматически перескакивают при фиксации) ревизию в ветках. По сути является аналогом веток в Git. Были введены не сразу (видимо как раз для удобства людей переходящих с Git).
3. Теги — символические указатели на произвольную ревизию. В отличие от закладок никуда не перескакивают и в отличие от имён веток не наследуются и могут изменяться.
Так вот нормальная работа с Mercurial вполне возможна (и вполне себе встречается) без всех этих трёх пунктов. Они существуют только для дополнительного удобства. Теперь понятно? )
_>>Почему-то пользователи git путают "branch name" (всего лишь атрибут ревизии) и реальные ветки (а вот их в упор не видят, хотя они и являются основным инструментом). И в результате получают глупости типа описанных в последнем предложение по моей ссылке. ))) N>Не "пользователи git", не надо натяжек, а все, кто не пришёл к этому "дети, это невозможно понять, но это надо запомнить". Я пытался разобраться с Hg, ещё не зная Git, запутался в этом бардаке, плюнул и забыл. Зато потом с Git было всё просто и понятно.
Не, это как раз пользователи Git привыкли к одной концепции и им приходится рассказывать что бывают другие варианты. Вот даже такие http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/ статейки выпускают (обрати внимание, что там везде объяснение через сравнение с git). Хотя на мой взгляд они только запутывают, потому как не соответствуют даже официальной документации. )))
_>>Так а может ты пояснишь, какой аналог анонимных веток у нас в git? ) Т.е. что делать при нескольких параллельных изменения относительно одной родительской ревизии, обязательно заводить отдельную именованную ветку? ) N>Да. Это чуть больше работы, но это небольшая цена за внятность концепции.
Это как раз в Git всё сложнее, т.к. требует обязательных команд по ручном созданию веток. Вместо очевидного понимания того факта, что любая родительская связь между двумя ревизиями автоматически является веткой. )
_>>Ну давай объясни мне в какой момент произойдёт на практике это чудесная автоматическая перепаковка. Вот завёл я чистый репозиторий. Кинул в него несколько больших (для удобства теста) текстовых файлов — ничего нет. Добавил несколько ревизий — всё равно ничего нет (а размер хранилища уже за мегабайт вылезает, в то время как у mercurial намного меньше). Так когда же? ) N>`git help gc` рассказывает это. Мегабайт не тот размер, о котором считается осмысленным заботиться (хотя оно считает не по объёму, а по количеству объектов и паков). N>С другой стороны, ряд источников говорит "выполняйте gc регулярно в на другой подходящий момент, например, при уходе на обеденный перерыв".
Ну в общем как я и говорил) Или мы делаем это руками или же преимущество в размере остаётся только в теории. )
_>>Ага, ага http://draketo.de/proj/hg-vs-git-server/test-results.html. Или это слишком сложно и детально? ) N>Это люди фатально не умеют рисовать графики — за такие рисунки отправлять в третий класс на пересдачу основ. Разбираться в однопиксельных пометках не стал, пошёл сразу к выводам. Пишут, что репо Git в среднем больше, если не начинается много веток, тогда оно меньше. Учитывая типичный стиль работы над действительно большим и серьёзным проектом, где обычно веток много (подготовки релизов, конкретные релизы, трейны апдейтов, параллельные трейны с перетеканием отлаженных фич), это важнее, чем на просто линейной истории.
Что-то ты какие-то странные выводы нашёл там. ) Я прочитал совсем другое. Люди там тестируют эти две системы в контексте организации сервера (на много пользователей). Т.е. для них и время работы и размер хранилища принципиальны. Соответственно в результатах у них показано, что git дико отжирает пространство на диске (собственно ради этого факта я и показал эту ссылку), а потом ещё и переодически загружает на время весь компьютер (если включено git gc --auto). В случае же настройки git gc через каждые несколько фиксаций с размером всё в порядке, но скорость работы получается существенно меньше Mercurial. Так что в итоге авторы тестирования рекомендуют использовать Mercurial.
Понятно, что для обычного (не серверного) применения это всё вообще не принципиально и обе системы подходят нормально. Однако в контексте нашей дискуссии о принципиальных преимуществах разных архитектурных подходов этот тест выявляет очень интересные результаты.
_>>Берём текстовый файл на мегабайт (чтобы ясно была разница, а то там всякие накладные расходы и т.п.). Кидаем в чистый репозиторий. Фиксируем ревизию. Меняем одну строчку в файле, снова фиксируем. Делаем пакет (bundle) из одной последней ревизии N>Что такое bundle?
git bundle create test1 -1 master
git bundle create test2 -2 master
_>>·>"хранилище mercurial занимает меньше места" — не согласен, т.к. надо рассматривать пакованный репо, ибо в реальности репы пакованные. _>>Пакованным они будут до добавления новых ревизий, т.е. очень не долго. ) N>Они останутся до перепаковки. Новые ревизии добавят новые непакованные объекты, факт. Но старые трогать никто не будет, пока не придёт gc, repack или аналог.
Достаточно поменять большую часть файлов проекта, чтобы хранилище снова дико выросло.
_>>Ну для начала с "много места" мы ещё и не разобрались. И кстати говоря у всех подходов есть свои недостатки. Даже если взять за основу идею с repack'ом, то помимо проблем с расписанием данной работы, данная техника к примеру блокирует возможность инкрементальных бэкапов хранилища. N>Именно в виде пофайловой копии .git/ — да. Но смысл такого копирования возникает только на репо, которое не может бэкапиться через банальный pull с запретом форсирований операций. А такие, как правило, отражают какие-то спецвиды возни вроде состояний, которые регулярно проходят через upstream rebase — это, например, ветки фида новых коммитов на рассмотрение в корневые репо Linux kernel. Формально проблема есть, практически же её важность крошечна.
Это ты говоришь про бэкап средствами самого git'а что ли?) Я имел в виду нормальный инкрементальный бэкап скажем всего диска или каталога с проектами соответствующими проф. инструментами.
Здравствуйте, netch80, Вы писали:
N>Skip дальше кусок — я понял, что у тебя в пределах ветки-1 (именованной базы роста) несколько веток-2 (просто направлений роста истории), которые ты потом сводишь, называя их своими идентификаторами. На самом деле в Git такое возможно, но если ты не дал имя такой голове, будешь знать только её id и её может удалить GC. Если ты гарантированно не допустишь GC, то можно так работать (rebase внутри себя так и делают). Только нафиг надо так корёжиться.
Ну так это только в git надо корёжится (не допускать gc, непонятным образом искать id и т.п.), а в mercurial это всё идеально удобно. Вот последовательность команд в Mercurial:
hg init
hg ci -A -m "init"
hg ci -m "change"
hg up 0
hg ci -m "alt change"
Создающая такой результат:
@ changeset: 2:c29317587b32
| tag: tip
| parent: 0:8fcdba93e475
| user: Alex
| date: Sat Feb 06 19:21:54 2016 +0300
| summary: alt change
|
| o changeset: 1:13d95e83fe25
|/ user: Alex
| date: Sat Feb 06 19:20:49 2016 +0300
| summary: change
|
o changeset: 0:8fcdba93e475
user: Alex
date: Sat Feb 06 19:19:45 2016 +0300
summary: init
Можно посмотреть для сравнения на набор команд git приводящий к аналогичному результату? )
И да, на это всё можно ещё сверху навесить и имена и закладки и теги, но зачем это всё в данном случае? )))
_>>Ну сейчас увидим как удобно будет. ) N>Удобства не увидел. Чтобы оно появилось, нужно, чтобы был смысл в параллельном развитии голов от одного разработчика и при этом переключаться между ними по идентификаторам, намеренно отказываясь от имён. Это уже религиозные заморочки, мне такое сложно понять.
Почему обязательно одного разработчика? )
Ну а насчёт удобства... Про принцип Оккама не забываем! )
Здравствуйте, netch80, Вы писали:
_>>Вроде как там ясно написано, что старым системам (cvs, svn и т.п.) ближе mercurial, а git наоборот отбросил все традиции и поэтому непривычен. Это полностью противоречит твой фразе о том, что к старым системам ближе git, а mercurial забил на традиции. N>Ну, там сказано немного иначе. Но если ты делаешь такие выводы, то тут я с коллегой "·" не согласен; и я не принимаю никакого упрёка просто из того, что кто-то ещё говорит иначе. Если ты хотел припугнуть меня чужим мнением, то это просто смешно в своей наивности.
Ну вообще то я просто надеялся что вы там между собой поспорите на эту тему и всё. ))) А так, по данному вопросу на самом деле вроде как общепринятое мнение, что система команд mercurial как раз ближе к классикe (типа cvs, svn). Что впрочем некоторые ставят как недостаток mercurial (типа ненужное наследие, в отличие от git). На мой взгляд это всё непринципиальные мелочи и если надо я легко могу пользоваться обеими системами без напряга. Но при свободе выбора очевидно выберу Mercurial из-за большего удобства.
Здравствуйте, alex_public, Вы писали:
_>Давай я сформулирую кратко всё что касается веток в Mercurial.
[...] _>Отдельно в Mercurial существует ещё несколько понятий, которые ты возможно путаешь: _>1. Имена веток — это просто неизменяемый атрибут ревизий с особым свойством, он автоматически передаётся всем наследникам данной ревизии (если руками не указано иного).
О. Вот тут твоя идеальная картина вдруг резко прекращается и начинается тысяча голодных дьяволов в мелочах. Начиная с того, что команда branch работает почему-то с вот этими "неизменяемыми атрибутами ревизий с особым свойством", что во всех найденных howto и объяснениях именно это называется веткой, что ты в начале дискуссии упорно доказывал, что именно это и есть ветки, а не то, что ты вдруг начал писать в этом постинге, и прочая, и прочая, и прочая.
И ни одно описание до сих пор это не описывало так, как ты сейчас описал. И то от тебя я этого добился только неоднократными упоминаниями разрыва между понятиями в стиле "ветка-1, ветка-2, ветка-3". И то — ты сейчас фактически ровно это же и описываешь.
_>2. Закладки — просто символические указатели (опциональные) на последнюю (автоматически перескакивают при фиксации) ревизию в ветках. По сути является аналогом веток в Git. Были введены не сразу (видимо как раз для удобства людей переходящих с Git).
Аналогом веток почти _везде_ кроме Hg. Начиная с того же CVS. Частично — и для SVN, если считать веткой базовый каталог и учитывать возможность прыжка между такими базами.
_>Так вот нормальная работа с Mercurial вполне возможна (и вполне себе встречается) без всех этих трёх пунктов. Они существуют только для дополнительного удобства. Теперь понятно? )
Понятно. В смысле, что в таком описании готов поверить — и даже счесть, что Hg нормально реализует ветки, при необходимом условии — для того, что у тебя под номером 1, будет введено другое название, соответственно обновлено всё начиная с имени команды и всех упоминаний в документации. Правда, это не единственное условие — надо ещё как минимум потестировать работу между разными репо. Тут уже посмотрим.
_>Не, это как раз пользователи Git привыкли к одной концепции и им приходится рассказывать что бывают другие варианты.
Я до Git работал с CVS и SVN. Нигде не было такого мозгоклюйства.
_>Вот даже такие http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/ статейки выпускают (обрати внимание, что там везде объяснение через сравнение с git). Хотя на мой взгляд они только запутывают, потому как не соответствуют даже официальной документации. )))
Вот именно. Во-первых, не соответствуют (тут верю тебе на слово). Во-вторых, авторы Hg явно зациклились на конкуренции с Git и не хотят смотреть в любом другом ключе. Хотя, если они ставят задачу забирать пользователей других систем, то им надо писать такие инструкции для SVN, CVS, VSS и тому подобного, а не Git, с которым соревноваться бессмысленно. А в данной инструкции как только читаешь "пролог" с "The default branch name in Mercurial is “default”.", сразу понятно, что этот автор только может ещё больше всё запутать.
_>Это как раз в Git всё сложнее, т.к. требует обязательных команд по ручном созданию веток.
Как раз то, что требуется обязательная команда, ничуть не говорит, что это сложнее. Необходимость явного действия — да. Сложнее — нет. Может быть, даже проще, потому что в Git ты уверен, что существуют головы DAG для того, что названо, и в нём нет ничего типа "забытая боковая ветка с данными, которые нельзя показывать другим, но которые тут таки прилепились".
К тому же, сам по себе сценарий типа "тут переехали назад по истории и начали рост от нового места" без внятной формулировки причины, зачем нужен этот самый рост, для меня выглядит банально нелепым. Если есть причина, надо её назвать хотя бы для себя и хотя бы для того, чтобы в истории не болталась забытая цепочка. А если она названа — она и будет названием ветки в общепринятом стиле.
_>Ну в общем как я и говорил) Или мы делаем это руками или же преимущество в размере остаётся только в теории. )
Я никогда не сталкивался с проблемами размера репо в Git. Возможно, это специфика каких-то особых условий. В любом случае, я не участвую тут в дискуссии по сравнению размеров и выборе на этой основе, я только сделал пару замечаний вскользь.
_>Понятно, что для обычного (не серверного) применения это всё вообще не принципиально и обе системы подходят нормально. Однако в контексте нашей дискуссии о принципиальных преимуществах разных архитектурных подходов этот тест выявляет очень интересные результаты.
А формат хранения истории вообще никак не относится к обсуждаемым нами ранее факторам — что такое ветка, где patch add, interactive rebase и тому подобное. Git приводится к варианту Hg в плане веток простейшим образом — хранить неназванные дополнительные головы. Я уже объяснил, почему считаю это не только бессмысленным, но и вредным. Но, если Git'овцы вдруг решат, что надо сменить методы упаковки для того, чтобы догнать Hg, это не повлияет не только на пользовательские средства верхнего уровня, но и на бо́льшую часть низкоуровневых средств (то, что в нём называется plumbing).
_>>>Берём текстовый файл на мегабайт (чтобы ясно была разница, а то там всякие накладные расходы и т.п.). Кидаем в чистый репозиторий. Фиксируем ревизию. Меняем одну строчку в файле, снова фиксируем. Делаем пакет (bundle) из одной последней ревизии N>>Что такое bundle?
_>git bundle create test1 -1 master _>git bundle create test2 -2 master
Ну, если ты знаешь, как провести эти тесты — покажи скрипты и результаты. Не думаю, что они покажут что-то принципиально важное (я лучше бы для сравнения взял результат перегонки чего-то открытого активно разрабатываемого), но просто покрасоваться цифрами — сгодится.
N>>Они останутся до перепаковки. Новые ревизии добавят новые непакованные объекты, факт. Но старые трогать никто не будет, пока не придёт gc, repack или аналог. _>Достаточно поменять большую часть файлов проекта, чтобы хранилище снова дико выросло.
Да. До упаковки.
_>Это ты говоришь про бэкап средствами самого git'а что ли?) Я имел в виду нормальный инкрементальный бэкап скажем всего диска или каталога с проектами соответствующими проф. инструментами.
При частых бэкапах перепаковка будет только на малой части от всех проектов, а при редкой изменение будет крупным для любой из обсуждаемых систем. Не думаю, что будет серьёзная разница.
Здравствуйте, ·, Вы писали:
_>>Здесь https://www.mercurial-scm.org/wiki/Branch всё подробно рассказано. Почему-то пользователи git путают "branch name" (всего лишь атрибут ревизии) и реальные ветки (а вот их в упор не видят, хотя они и являются основным инструментом). ·>Может я буквы читать разучился, но покажи в какой позиции в строке "you must first pull the head of that development line " находится слово "branch"? ·>В документации branch — это такой монстр, имя которого хранится в атрибуте, у которого есть множество heads. А ещё есть development line, related repositories. А ещё, оказывается, hg мержит не branches, а lines of development. ·>Столько ненужной и лишней терминологии просто из-за кривого дизайна системы.
Рекомендую читать с начала:
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.
_>>И в результате получают глупости типа описанных в последнем предложение по моей ссылке. ))) ·>Которой ссылке? Я правильно понял, ты имеешь в виду что в официальной документации hg написана глупость?
Нет, там корректно написано каким путём можно привести систему в глупое состояние. )
_>>А расскажи, чем по твоему неудобны глобальные имена веток? ) ·>Тем что это противоречит распределённости. Лишняя сущность, которая нужна далеко не всегда. Что плохого в том, если два разработчика создадут ветки "experiment", а потом захотят обменяться?
И в чём будет проблема с этим в Mercurial? )
_>>Про номера ревизий не понял в чём проблема, это всего лишь локальные хоткеи для удобства (если не хочешь, можешь вообще не обращать на них внимание) адресации. ·>Ещё одна ненужная нашлёпка сбоку, унаследованная от cvcs.
А людям удобно. ) Тем же кому не надо, ничем не мешает. Непонятно что плохого.
_>>Ну так правильно, heads то показывает не все существующие ветки в репозитории, а только некое подмножество — не слитые. А heads <branchname> показывает ещё более мелкое подмножество — помеченные определённым именем. ·>Объясни, каким словарём ты пользуешься, что словосочетание "branch heads" ты переводишь как "ветки"? Или в документаци, как всегда, глупость написана?
Ну естественно что branch heads — это не ветки, а соответствующие ревизии. Но т.к. их число будет в точности равно числу не слитых веток, то думаю что моя фраза была вполне понятна.
_>>Так а может ты пояснишь, какой аналог анонимных веток у нас в git? ) Т.е. что делать при нескольких параллельных изменения относительно одной родительской ревизии, обязательно заводить отдельную именованную ветку? ) ·>А если не обязательно параллельных? ·>В общем да, можно и ветку завести — ибо это ничего не стоит и никаких сложностей не создаёт. Это же не hg, где если заведёшь ветку, то это "навсегда". Собственно эта "фича" hg продиктована необходимостью — ветку завести не всегда возможно, вот и пришлось придумать новую сущность — головы.
Никакой сущности "головы" в mercurial нет. ))) А команда heads просто показывает список ревизий без потомков (соответственно это получается список конечных ревизий, по одной для каждой ветки).
·>Ещё можно просто по sha1 обращаться. Можно reflog полистать, можно в stash закинуть. Вариантов куча.
Ага, очень удобно. ) Да, и не забудь заблокировать git gc при этом. )))
_>>Ну давай объясни мне в какой момент произойдёт на практике это чудесная автоматическая перепаковка. Вот завёл я чистый репозиторий. Кинул в него несколько больших (для удобства теста) текстовых файлов — ничего нет. Добавил несколько ревизий — всё равно ничего нет (а размер хранилища уже за мегабайт вылезает, в то время как у mercurial намного меньше). Так когда же? ) ·>Если хочешь разобраться досконально, читай хелп на "git gc", флажок --auto. Там точно указаны правила. Используются несколько имперически подобранных параметров, чтобы в более менее стандартных ситуациях давать хороший результат, если что — можно подкрутить для особых случаев. Вроде очевидно, что "несколько мегабайт" это не то, о чём стоит волноваться.
Я согласен, что для обычного пользователя это всё не принципиально. Но мы то рассуждаем об архитектурных принципах. И пока что выходит что на практике (а не в теории, где все тесты производятся после repack) подход mercurial лучше.
_>>Ага, ага http://draketo.de/proj/hg-vs-git-server/test-results.html. Или это слишком сложно и детально? ) ·>Графики каие-то нечитабельные. И я не понял — а что именно там коммитилось-то? Что-то какие-то случайные модификации каких-то случайных данных...
написал про эту ссылку. Если же кратко, то главное для нашей дискуссии там показано, что в обычном режиме (не с настройкой git-gc через каждый несколько фиксаций) хранилище git начинает отжирать неадекватно много места.
·>Так новые ревизии не заставляют репозиторий распаковываться. То что запаковалось — так и остаётся запакованным.
А я этого и не утверждал. Я говорил что размер снова вырастет через несколько новых ревизий. )
_>>Берём текстовый файл на мегабайт (чтобы ясно была разница, а то там всякие накладные расходы и т.п.). Кидаем в чистый репозиторий. Фиксируем ревизию. Меняем одну строчку в файле, снова фиксируем. Делаем пакет (bundle) из одной последней ревизии и смотрим размер файла (число1, должно быть очень маленькое), делаем пакет из двух последних ревизий (по сути будет весь репозиторий) и смотрим размер файла (число2, должно быть большое). Выполняем эту последовательность и для mercurial и для git, а потом сравниваем в начале две версии числа1, а потом две версии числа 2. ·>
·>kan@altegol:~/tmp/experiment/bundle/git$ ls -l
·>total 1424
·>-rw-rw-r-- 1 kan kan 228253 Feb 6 13:25 1.bundle
·>-rw-rw-r-- 1 kan kan 419 Feb 6 13:26 2.bundle
·>-rw-rw-r-- 1 kan kan 1198368 Feb 6 13:18 file
·>kan@altegol:~/tmp/experiment/bundle/hg$ ls -l
·>total 1356
·>-rw-rw-r-- 1 kan kan 157286 Feb 6 13:41 1.bundle
·>-rw-rw-r-- 1 kan kan 399 Feb 6 13:42 2.bundle
·>-rw-rw-r-- 1 kan kan 1198368 Feb 6 13:39 file
·>
·>Разница есть, конечно, но не принципиальна... Вообще не понимаю причём тут бандлы, они от структуры репозитория не зависят.
Потому что они идеально характеризуют тот объём данных, который необходимо переслать по сети для соответствующей синхронизации репозиториев. Можно конечно и честно по сети замерять, но это намного сложнее. Ну а соответственно размер этих файлов даёт представление о качестве алгоритмов эти двух систем... )
_>>Ну для начала с "много места" мы ещё и не разобрались. И кстати говоря у всех подходов есть свои недостатки. Даже если взять за основу идею с repack'ом, то помимо проблем с расписанием данной работы, данная техника к примеру блокирует возможность инкрементальных бэкапов хранилища. ·>Не блокирует. Просто иногда после repack придётся новые паки бэкапить, старые удалять, вот и всё. А вообще не проще ли --mirror использовать или тупо rsync?
Ну о пользе и недостатках инкрементального бэкапа можно отдельно говорить. Но факт в том, что операция repack в git сильно вредит данной технике.
Здравствуйте, alex_public, Вы писали:
_>Ну так это только в git надо корёжится (не допускать gc, непонятным образом искать id и т.п.), а в mercurial это всё идеально удобно.
Если хочешь дальше общаться, прекращай это НЛП в виде регулярной мантры "идеально удобно", или я просто прекращу обсуждение и буду считать тебе техническое поражение. Надоело. Или мы говорим проверяемыми аргументами без вкусовщины (во что входит соответствие общепринятым терминам и распространённым практикам), или мне такое не подходит.
_> Вот последовательность команд в Mercurial:
Тему веток я прокомментировал ровно один свой комментарий назад в этой ветке.
_>И да, на это всё можно ещё сверху навесить и имена и закладки и теги, но зачем это всё в данном случае? )))
Там же был и ответ, зачем.
_>>>Ну сейчас увидим как удобно будет. ) N>>Удобства не увидел. Чтобы оно появилось, нужно, чтобы был смысл в параллельном развитии голов от одного разработчика и при этом переключаться между ними по идентификаторам, намеренно отказываясь от имён. Это уже религиозные заморочки, мне такое сложно понять. _>Почему обязательно одного разработчика? )
Ну ok. От нескольких. И опять же всё без имён, только по идентификаторам коммитов. А потом за них же цепляться и сводить воедино.
_>Ну а насчёт удобства... Про принцип Оккама не забываем! )
И что он тут даёт в твою пользу? В мою вижу — появилась излишняя сущность "безымянные цепочки" с диверсионными последствиями.
Здравствуйте, alex_public, Вы писали:
a> 1. Имена веток — это просто неизменяемый атрибут ревизий с особым свойством, он автоматически передаётся всем наследникам данной ревизии (если руками не указано иного).
А чем это полезно? На пальцах.
Ну и чтобы 2 раза не вставать: если я когда-то создал ветку с именем branch1, то я больше никогда не смогу создать другую ветку с таким же именем? И более того имена глобальны для всех репо?
Здравствуйте, netch80, Вы писали:
_>>Отдельно в Mercurial существует ещё несколько понятий, которые ты возможно путаешь: _>>1. Имена веток — это просто неизменяемый атрибут ревизий с особым свойством, он автоматически передаётся всем наследникам данной ревизии (если руками не указано иного). N>О. Вот тут твоя идеальная картина вдруг резко прекращается и начинается тысяча голодных дьяволов в мелочах. Начиная с того, что команда branch работает почему-то с вот этими "неизменяемыми атрибутами ревизий с особым свойством", что во всех найденных howto и объяснениях именно это называется веткой, что ты в начале дискуссии упорно доказывал, что именно это и есть ветки, а не то, что ты вдруг начал писать в этом постинге, и прочая, и прочая, и прочая.
Так где оно называется то так? Скажем при описание какой-нибудь команды с возможным параметром в виде этого самого атрибута (введённого специально для идентификации неанонимных веток). Ты думаешь кто-то будет писать "передаём команде специальный атрибут branch1, идентифицирующий нашу ветку"? Естественно все пишут "передаём команде ветку branch1".
_>>2. Закладки — просто символические указатели (опциональные) на последнюю (автоматически перескакивают при фиксации) ревизию в ветках. По сути является аналогом веток в Git. Были введены не сразу (видимо как раз для удобства людей переходящих с Git). N>Аналогом веток почти _везде_ кроме Hg. Начиная с того же CVS. Частично — и для SVN, если считать веткой базовый каталог и учитывать возможность прыжка между такими базами.
Неизменность истории мне нравится больше)
_>>Вот даже такие http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/ статейки выпускают (обрати внимание, что там везде объяснение через сравнение с git). Хотя на мой взгляд они только запутывают, потому как не соответствуют даже официальной документации. ))) N>Вот именно. Во-первых, не соответствуют (тут верю тебе на слово). Во-вторых, авторы Hg явно зациклились на конкуренции с Git и не хотят смотреть в любом другом ключе. Хотя, если они ставят задачу забирать пользователей других систем, то им надо писать такие инструкции для SVN, CVS, VSS и тому подобного, а не Git, с которым соревноваться бессмысленно. А в данной инструкции как только читаешь "пролог" с "The default branch name in Mercurial is “default”.", сразу понятно, что этот автор только может ещё больше всё запутать.
Ну вообще то раньше (до популярности гитхаба) со старых систем как раз чаще переходили на Mercurial в силу более привычной системы команд. Сейчас же из-за распиаренности гитхаба чаще переходят на git и страдают потом с ним. ) Ну это естественно если руками в консоли работают. При классической работе через плагин в IDE разницы между этими двумя DVCS почти не будет.
N>К тому же, сам по себе сценарий типа "тут переехали назад по истории и начали рост от нового места" без внятной формулировки причины, зачем нужен этот самый рост, для меня выглядит банально нелепым. Если есть причина, надо её назвать хотя бы для себя и хотя бы для того, чтобы в истории не болталась забытая цепочка. А если она названа — она и будет названием ветки в общепринятом стиле.
А если причиной развилки будет всего лишь синхронизация изменений с двух разных машин? )
_>>>>Берём текстовый файл на мегабайт (чтобы ясно была разница, а то там всякие накладные расходы и т.п.). Кидаем в чистый репозиторий. Фиксируем ревизию. Меняем одну строчку в файле, снова фиксируем. Делаем пакет (bundle) из одной последней ревизии N>>>Что такое bundle? _>>git bundle create test1 -1 master _>>git bundle create test2 -2 master N>Ну, если ты знаешь, как провести эти тесты — покажи скрипты и результаты. Не думаю, что они покажут что-то принципиально важное (я лучше бы для сравнения взял результат перегонки чего-то открытого активно разрабатываемого), но просто покрасоваться цифрами — сгодится.
Ну тут уже кидали результаты. У меня в принципе похожие — у Mercurial раза в 1,5 меньше получаются пакеты изменений. ) Т.е. где-то так же и сеть загружается при синхронизации.
хотя нет, для этого нужен ещё и аналог гитового index с полноценной поддержкой, и interactive rebase с его возможностями по расщеплению, слиянию и перестановке коммитов, модификации батчем. Вот после этого для меня они будут близки к эквивалентам.
