Сообщение Re[23]: Git wtf?.. от 06.02.2016 16:15
Изменено 06.02.2016 17:19 alex_public
Здравствуйте, 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.
Понятно, что для обычного (не серверного) применения это всё вообще не принципиально и обе системы подходят нормально. Однако в контексте нашей дискуссии о принципиальных преимуществах разных архитектурных подходов этот тест выявляет очень интересные результаты.
_>> Тогда рекомендую глянуть на такие http://stackoverflow.com/questions/6969385/why-is-my-git-repository-so-much-larger-than-mercurial-version вопросы, периодически возникающие на SO и т.п. местах.
N>А тут проскакивает, что преимущество Hg в сжатии диффов бинарников. Опять же сомнительное удовольствие (я в рамках благостных пожеланий "а хорошо бы такое увидеть", конечно, хочу, но в реальной жизни как-то не сталкивался — это что ж за бинарники такие, что между версиями можно получить компактный diff?)
С каких это пор sql файлы стали бинарниками? )
_>>Берём текстовый файл на мегабайт (чтобы ясно была разница, а то там всякие накладные расходы и т.п.). Кидаем в чистый репозиторий. Фиксируем ревизию. Меняем одну строчку в файле, снова фиксируем. Делаем пакет (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'а что ли?) Я имел в виду нормальный инкрементальный бэкап скажем всего диска или каталога с проектами соответствующими проф. инструментами.
_>>Здесь 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.
Понятно, что для обычного (не серверного) применения это всё вообще не принципиально и обе системы подходят нормально. Однако в контексте нашей дискуссии о принципиальных преимуществах разных архитектурных подходов этот тест выявляет очень интересные результаты.
_>> Тогда рекомендую глянуть на такие http://stackoverflow.com/questions/6969385/why-is-my-git-repository-so-much-larger-than-mercurial-version вопросы, периодически возникающие на SO и т.п. местах.
N>А тут проскакивает, что преимущество Hg в сжатии диффов бинарников. Опять же сомнительное удовольствие (я в рамках благостных пожеланий "а хорошо бы такое увидеть", конечно, хочу, но в реальной жизни как-то не сталкивался — это что ж за бинарники такие, что между версиями можно получить компактный diff?)
С каких это пор sql файлы стали бинарниками? )
_>>Берём текстовый файл на мегабайт (чтобы ясно была разница, а то там всякие накладные расходы и т.п.). Кидаем в чистый репозиторий. Фиксируем ревизию. Меняем одну строчку в файле, снова фиксируем. Делаем пакет (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'а что ли?) Я имел в виду нормальный инкрементальный бэкап скажем всего диска или каталога с проектами соответствующими проф. инструментами.
Re[23]: Git wtf?..
Здравствуйте, 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'а что ли?) Я имел в виду нормальный инкрементальный бэкап скажем всего диска или каталога с проектами соответствующими проф. инструментами.
_>>Здесь 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'а что ли?) Я имел в виду нормальный инкрементальный бэкап скажем всего диска или каталога с проектами соответствующими проф. инструментами.