git vs mercurial (было "vcs vs vcs")

[t.t]

При таком подходе именованные ветки не нужны, следует держать отдельные клоны репозитория, как это и рекомендуется в hgbook.

Круг -дцатый. Я уже привёл use case'ы, когда ветки hg неудобны по сравнению с git.

Поправка: ты привёл use case-ы, в которых в hg применяются не именованные ветки, а другие инструменты: теги, анонимные ветки, под-репозитории (subrepo), клоны.

Можете привести use case, когда ветки hg имеют явное преимущество? Например, зачем может понадобиться знать, какой ветке принадлежит(ал) какой-то там ченджсет в истории?

Например, проанализировать багфиксы, внесённые в конкретный релиз: всего лишь пропрыгать changeset-ы внутри конкретной ветки.

Кстати, а какой ветке он принадлежит, если до него можно дойти из головы development, release-1.0 и release-2.0?

А это зависит. Если именно в этом примере, то, учитывая логику последовательности ветвтления, скорее всего development. И это более чем логично: ведь _в тот момент_ это действительно был development. Т.е. доработки, вносимые на стадии активной разработки, будут в ветке devel; весь код, внесённые на этапе тестирования -- в ветке testing; а багфиксы -- в ветке release; либо, если release ветвить и дальше, как ты указал выше, то в release-1 будут багфиксы, внесённые именно в этот релиз.

[t.t]

Если история нелинейная, то очевидно что в какой-то момент было две головы )

У ветки никогда не было двух голов. В какой-то момент было две ветки, разных, с разными именами, потом они слились. Но голова у каждой ветки в каждый момент одна.

Ты забыл про анонимные ветки. Ветки, которые "в какой-то момент были разными, потом слились" в большинстве случаев анонимные (или по крайней мере одна из них анонимная). При этом обе этих параллельных анонимных ветки могут быть внутри одной именованной ветки. В этом случае на момент их существования у именованной ветки действительно будет две головы.

Вот с анонимными ветками другая история: у них действительно больше одной головы быть не может, т.к. кажда новая голова -- это уже другая анонимная ветка.

[watashiwa_daredeska]

ты привёл use case-ы, в которых в hg применяются не именованные ветки, а другие инструменты: теги, анонимные ветки, под-репозитории (subrepo), клоны.

Да, а теперь я хочу услышать use case, показывающий полезность данной конкретной дополнительной сущности, ибо на данный момент, я вижу, что на все случаи жизни достаточно других инструментов, но тот же git позволяет обойтись одним репозиторием, когда hg требуется создание клона.

багфиксы, внесённые в конкретный релиз: всего лишь пропрыгать changeset-ы внутри конкретной ветки.

Если именно в этом примере, то, учитывая логику последовательности ветвтления, скорее всего development.

И как прикажешь «всего лишь пропрыгать changeset'ы внутри конкретной ветки», если они в development? Не вносится, обычно, в релизную ветку никаких изменений, только мержатся из других веток, т.е. фактически, changeset'ов в релизной ветке не будет, окромя мержей, но это совершенный misguide тогда.

Ты забыл про анонимные ветки. Ветки, которые "в какой-то момент были разными, потом слились" в большинстве случаев анонимные (или по крайней мере одна из них анонимная).

Ага. Т.е. анонимные ветки — это и есть те ветки, которые в git. А им временно имя можно какое-то присвоить? bookmark — это оно?

[Crazy]

Интересно, что в сухом остатке, от сравнения разных систем?

[t.t]

ты привёл use case-ы, в которых в hg применяются не именованные ветки, а другие инструменты: теги, анонимные ветки, под-репозитории (subrepo), клоны.

Да, а теперь я хочу услышать use case, показывающий полезность данной конкретной дополнительной сущности, ибо на данный момент, я вижу, что на все случаи жизни достаточно других инструментов, но тот же git позволяет обойтись одним репозиторием, когда hg требуется создание клона.

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

багфиксы, внесённые в конкретный релиз: всего лишь пропрыгать changeset-ы внутри конкретной ветки.

Если именно в этом примере, то, учитывая логику последовательности ветвтления, скорее всего development.

И как прикажешь «всего лишь пропрыгать changeset'ы внутри конкретной ветки», если они в development?

Подожди, я не говорил, что это один и тот же случай. Это во-первых. Во-вторых, я сказал "скорее всего", т.е. возможны варианты. И наконец, почему ты решил, что конкретный changeset может принадлежать только одной именованной ветке?

Не вносится, обычно, в релизную ветку никаких изменений, только мержатся из других веток, т.е. фактически, changeset'ов в релизной ветке не будет, окромя мержей, но это совершенный misguide тогда.

Видимо, я не совсем верно или не совсем внятно выразился. Завтра на свежую голову перечитаю и попробую объяснить.

Ты забыл про анонимные ветки. Ветки, которые "в какой-то момент были разными, потом слились" в большинстве случаев анонимные (или по крайней мере одна из них анонимная).

Ага. Т.е. анонимные ветки — это и есть те ветки, которые в git.

Не совсем. На самом деле прямых аналогий между гитовскими и меркуриаловскими ветками нет.

А им временно имя можно какое-то присвоить? bookmark — это оно?

Если ты имеешь ввиду имя внутри конкретного хранилища (не мигрирующее при клонах), то да.

[t.t]

Интересно, что в сухом остатке, от сравнения разных систем?

Я этот сухой остаток попытался сформулировать ещё в начале темы: выбор субъективен и контекстно-зависим. Кое-кто здесь не согласился, но я так и не понял, с чем. Конкретных ситуаций, в которых было бы явное преимущество одной из систем, лично я пока назвать не могу (да и сказать, есть ли они вообще). "Продолжаем разговор". ©

[watashiwa_daredeska]

Не увидел в этой теме примера применения клонов, в котором не было бы альтернативных решений.

При таком подходе именованные ветки не нужны, следует держать отдельные клоны репозитория, как это и рекомендуется в hgbook.

Не?

И наконец, почему ты решил, что конкретный changeset может принадлежать только одной именованной ветке?

О боже. Я совсем перестал понимать принцип реализации этой штуки :)

А что получится, если в истории, прослеживаемой с головы ветки, changset'ы помечены этой веткой пунктиром (ну, т.е. история HEAD -> A -> B -> C, где A и C помечены, а B нет)?

В целом, я понял, что лично для меня, «именованные ветки» hg — лишняя заумная сущность, а некоторые вещи, которыми я пользуюсь, hg делает неудобно.

[Crazy]

Интересно, что в сухом остатке, от сравнения разных систем?

Я этот сухой остаток попытался сформулировать ещё в начале темы: выбор субъективен и контекстно-зависим. Кое-кто здесь не согласился, но я так и не понял, с чем. Конкретных ситуаций, в которых было бы явное преимущество одной из систем, лично я пока назвать не могу (да и сказать, есть ли они вообще). "Продолжаем разговор". ©

Спасибо за разъяснения. На месте прохождение практики освоил svn, про git только читал.

[sash-kan]

зарекался/зарекался, но ещё раз отвечу не по порядку (новый участник дискуссии объявлся, всё-таки).

Интересно, что в сухом остатке, от сравнения разных систем?

насколько я понимаю, пока со скрипом и оговорками главный защитник mercurial признал только бОльшую функциональность git-а.
по всем остальным фронтам идёт яростное сопротивление.
(улыбка)

[drBatty]

насколько я понимаю, пока со скрипом и оговорками главный защитник mercurial признал только бОльшую функциональность git-а.
по всем остальным фронтам идёт яростное сопротивление.
(улыбка)

точнее: большую перегруженность излишним функционалом. лично мне, для моих мелких проектов вполне достаточно hg, mozilla тоже не жалуется (хотя их проекты в 49 000+ файлов сложно назвать мелкими), потому лично я не собираюсь переходить на git - пусть Линус своё ядро там делает (:

[kamre]

Не увидел в этой теме примера применения клонов, в котором не было бы альтернативных решений.

При таком подходе именованные ветки не нужны, следует держать отдельные клоны репозитория, как это и рекомендуется в hgbook.

Не?

Я тогда не совсем верно написал, вот неплохое описание про использование веток в hg: http://stevelosh.com/blog/2009/08/a-guide-...g-in-mercurial/

[t.t]

главный защитник mercurial

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

Интересно, что в сухом остатке, от сравнения разных систем?

насколько я понимаю, пока со скрипом и оговорками главный защитник mercurial признал только бОльшую функциональность git-а.

Да, позволю себе процитировать к слову одну из скрипящих оговорок:

насколько я понимаю, пока со скрипом и оговорками главный защитник mercurial признал только бОльшую функциональность git-а.

точнее: большую перегруженность излишним функционалом.

по всем остальным фронтам идёт яростное сопротивление.
(улыбка)

Действительно яростное: ты даже, кажется, собирался собственные тесты производительности проводить. (:

[t.t]

Не увидел в этой теме примера применения клонов, в котором не было бы альтернативных решений.

При таком подходе именованные ветки не нужны, следует держать отдельные клоны репозитория, как это и рекомендуется в hgbook.

Не?

Уже ответили.

И наконец, почему ты решил, что конкретный changeset может принадлежать только одной именованной ветке?

О боже. Я совсем перестал понимать принцип реализации этой штуки

Я же говорю, это от склада ума зависит: я, например, в принципах git многого так и не понял.

А что получится, если в истории, прослеживаемой с головы ветки, changset'ы помечены этой веткой пунктиром (ну, т.е. история HEAD -> A -> B -> C, где A и C помечены, а B нет)?

Как ты себе такое представляешь, откуда вообще может возникнуть такая ситуация?

В целом, я понял, что лично для меня, «именованные ветки» hg — лишняя заумная сущность, а некоторые вещи, которыми я пользуюсь, hg делает неудобно.

Что в очередной раз подтверждает субъективность выбора -- основной мой тезис в этой ветке. (: Я могу практически симметрично выразиться о git.

[t.t]

вот неплохое описание про использование веток в hg: http://stevelosh.com/blog/2009/08/a-guide-...g-in-mercurial/

Я, кстати, уже даже приводил здесь эту ссылку. Приведу ещё одну, на оригинальный пост, на основе которого это было написано:
http://a.longreply.com/178502

И позволю себе привести одну цитату из этого поста:

Sometimes I don't want to think up a name for a quick-fix branch. With git I have to name it if I want to really do anything with it, with Mercurial I don't. Sometimes I want to have the branch name as part of the commit's metadata. With git I can't, with Mercurial I can. Mercurial's branching is more flexible than git's, not less.

[t.t]

И позволю себе привести одну цитату из этого поста:

Sometimes I don't want to think up a name for a quick-fix branch. With git I have to name it if I want to really do anything with it, with Mercurial I don't. Sometimes I want to have the branch name as part of the commit's metadata. With git I can't, with Mercurial I can. Mercurial's branching is more flexible than git's, not less.

Это я опять же к тому, что высказывания типа "git более функционален" или "функциональность hg, которой нет у git, это лишь дополнительная ненужная сущность" сугубо субъективны -- для кого-то другого может быть строго наоборот.

[sash-kan]

Следующее найденное мною сравнение столь нейтрально и столь познавательно, что его я не буду цитировать, а рекомендую прочитать полностью:
http://rg03.wordpress.com/2009/04/07/mercurial-vs-git/

всё, что там написано, изложено во всевозможных документациях.
ну, если кому-то это изложение покажется полезным, то и хорошо.

ты даже, кажется, собирался собственные тесты производительности проводить.

напоминаю: ссылку на документ я выложил. по мере свободного времени и желания буду его дополнять.

[t.t]

Следующее найденное мною сравнение столь нейтрально и столь познавательно, что его я не буду цитировать, а рекомендую прочитать полностью:
http://rg03.wordpress.com/2009/04/07/mercurial-vs-git/

всё, что там написано, изложено во всевозможных документациях.
ну, если кому-то это изложение покажется полезным, то и хорошо.

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

ты даже, кажется, собирался собственные тесты производительности проводить.

напоминаю: ссылку на документ я выложил. по мере свободного времени и желания буду его дополнять.

Что-то я не помню, видел ли. Пойду посмотрю.

[deadhead]

Что-то я не помню, видел ли. Пойду посмотрю.

Далеко ходить не надо ;-) тыц

[t.t]

ты даже, кажется, собирался собственные тесты производительности проводить.

напоминаю: ссылку на документ я выложил. по мере свободного времени и желания буду его дополнять.

Что-то я не помню, видел ли. Пойду посмотрю.

Да, видел. Те тесты, которые там уже есть, не говорят почти ни о чём: init пришлось повторить сто раз только чтобы померять (т.е. ощутимым для человека нельзя считать даже, хотя бы, десятикратное повторение -- а кто создаёт хранилища сразу десятками?); и импорт из svn далеко не повседневная операция, а во многих случаях вообще не нужная ни разу, т.е. здесь всё опять же контекстно-зависимо.

[t.t]

Что-то я не помню, видел ли. Пойду посмотрю.

Далеко ходить не надо ;-)тыц

Я понял, спасибо. (:

[t.t]

Нашёл у git ощутимое для меня преимущество: он есть в стандартных репозиториях maemo4. У меня сейчас почти вся работа на n810 сосредоточилась — давно пора начать её историю сохранять, а про svn как-то после mercurial-а вспоминать не хотелось.

И я тут поразмыслил по случаю… На самом деле, преимущества mercurial лично для меня, в отрыве от офиса, где для новых сотрудников очень важна простота, оказались не столь значительными, чтобы однозначно перекрыть преимущества git.

Так что буду осваивать. (:

[sash-kan]

Так что буду осваивать.

удачи. ежели что — подсобим.

[t.t]

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

Т.е. по тем двум случаям применения, которые были лично у меня, я бы сейчас сказал так:
1. Для быстрорастущего коммерческого проекта, где нужна строгая иерархия, жёсткая «почти прямолинейная» структура и низкий порог вхождения для новичков, скорее всего лучше mercurial.
2. Для личного применения скорее всего лучше git.

[t.t]

Пока неприятно, что на каждый чих приходится создавать свои алиасы. Хотя это, конечно, разовая задача.

[t.t]

Хотя вот, кстати, для тех же виндоюзеров, у которых нет bash-completion, при работе в командной строке mercurial будет удобнее: там достаточно ввести столько букв, сколько нужно для однозначного определения имени команды. Например, hg st вместо status и hg sh вместо showconfig. Понятно, что это тоже решается алиасами, но всё же.

[Portnov]

Из .zshrc:

Код: Выделить всё

alias add='git add'
alias ci='git commit'
alias st='git status'
alias branch='git branch'
alias co='git checkout'
alias merge='git merge'
alias mergetool='git mergetool'
alias show='git show'
alias log='git log'
alias pull='git pull'
alias push='git push'

Как-то так.

[t.t]

Тоже вариант, конечно. Но мне всё же сподручнее гитовские алиасы (или меркуриаловские соответственно). По крайней мере, пока. Там видно будет.