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

[sash-kan]

У меня вообще возникло стойкое впечатление, что они стараются не замечать другие dvcs. Например, на офсайте mercurial и bazaar упоминаются _исключительно_ в одном ряду с svn, cvs и (sic!) Visual SourceSafe.

не знаю, честно говоря, откуда могло сложиться мнение о «незамечании».
а про один ряд это, случайно, не кореллирует с данным фрагментом:

Different from SVN

It is important to note that this is very different from most SCM systems that you may be familiar with. Subversion, CVS, Perforce, Mercurial and the like all use Delta Storage systems - they store the differences between one commit and the next. Git does not do this - it stores a snapshot of what all the files in your project look like in this tree structure each time you commit. This is a very important concept to understand when using Git.

Откуда сложилось мнение о незамечании других dvcs, я написал: оттуда, что упоминаются исключительно в одном ряду с cvcs, противоставляемыми гиту. Тогда как более обеъктивно противооставить все dvcs всем cvcs -- между этими двумя группами разница гораздо более существенна, чем между "git и всем остальным". Собственно, ты приведенной цитатой лишний раз эту необъективность продемонстрировал. (:

в приведённой мною цитате написана неправда? тогда я, извини, выбываю из темы (улыбка).

p.s. у меня сложилось впечатление, что ты в ответах мне общаешься не со мной, а продолжаешь какой-то собственный давний спор с кем-то посторонним.
отсюда, видимо, проистекают совершенно несвойственные тебе невнимательность и предвзятое отношение к «надоевшим гитовцам». хотя, скорее, это я слишком плохо формулирую свои мысли. есть за мной и такой грешок.

[t.t]

в приведённой мною цитате написана неправда? тогда я, извини, выбываю из темы (улыбка).

Я разве где-то использовал слово "неправда"? Я писал про необъективность, это разные вещи. В описании тех свойств git, которыми он отличается от всех остальных (по мнению его авторов, что понятно, в лучшую сторону), mercurial упоминается; а во всех остальных местах и особенно там, где описывается (также исключительно с положительной стороны, что тоже понятно) сам принцип распределённости, о нём сразу забывают.

p.s. у меня сложилось впечатление, что ты в ответах мне общаешься не со мной, а продолжаешь какой-то собственный давний спор с кем-то посторонним.
отсюда, видимо, проистекают совершенно несвойственные тебе невнимательность и предвзятое отношение к «надоевшим гитовцам». хотя, скорее, это я слишком плохо формулирую свои мысли. есть за мной и такой грешок.

У меня раньше не было подобных споров. Возможно, я действительно веду себя не слишком толерантно, т.к. у меня ощущение складывается, что ты постоянно троллишь -- причём именно в любимом стиле "надоевших гитовцев". Начиная с феерической фразы о том, что гит якобы быстрее cvcs и _тем более_ других dvcs. Которая, собственно, и породила этот спор.

[/dev/random]

Я разве где-то использовал слово "неправда"? Я писал про необъективность, это разные вещи. В описании тех свойств git, которыми он отличается от всех остальных (по мнению его авторов, что понятно, в лучшую сторону), mercurial упоминается; а во всех остальных местах и особенно там, где описывается (также исключительно с положительной стороны, что тоже понятно) сам принцип распределённости, о нём сразу забывают.

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

[t.t]

Я разве где-то использовал слово "неправда"? Я писал про необъективность, это разные вещи. В описании тех свойств git, которыми он отличается от всех остальных (по мнению его авторов, что понятно, в лучшую сторону), mercurial упоминается; а во всех остальных местах и особенно там, где описывается (также исключительно с положительной стороны, что тоже понятно) сам принцип распределённости, о нём сразу забывают.

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

Я не о том. Точных цитат сейчас не приведу, типичный пример "на пальцах". В описаниях mercurial: "в svn и cvs такие-то и такие-то недостатки; в распределённых системах всё не так". В описаниях git: "в svn и других scm такие-то и такие-то недостатки; в git всё не так". Разницу чувствуешь? И это не единичный пример, это общая практика, причём я выбрал ещё достаточно мягкую форму.

[watashiwa_daredeska]

Так что кто из двух лидеров лучше вписывается в unix-way -- это ещё можно поспорить. (:

Как выяснили выше, готовые vcs сами по себе практически равноценны по функциональным характеристикам. Но одна из них — практически монолит, а вторая собрана из конструктора, который доступен и пользователю. Вот эта самая дополнительная доступность конструктора и есть плюс, с моей т.з.

Можешь назвать _широко распространённые_ причины одновременного использования двух vcs для одного и того же кода?

Конечно. Коммит в репозиторий cvcs требует соблюдения определенных правил, иногда относительно трудоемких. Использование локальной dvcs позволяет наслаждаться всеми прелестями быстрого vcs без административного геморроя, пока не вылепится нечто, которое можно закоммитить. И да, центральный репозиторий может быть далеко и медленно.

[/dev/random]

Почему же не совсем? Думаю, очень многим от dvcs нужна только dvcs, а не ещё один конструктор. В частности, именно потому, что unix сам является конструктором, а dvcs во многих схемах лишь один из винтиков внутри него; который должен "делать одну задачу, но делать её хорошо". Так что кто из двух лидеров лучше вписывается в unix-way -- это ещё можно поспорить. (:

Ну, это всё равно, что называть юниксвейным аутпост, в котором и антитроян, и фаерволл, и сетевой монитор, и т.д., исходя из того, что он выполняет одну задачу - защиту компьютера.

В unix-way под "одной задачей" подразумевается одна низкоуровневая задача. А vcs - задача достаточно высокоуровневая.

[t.t]

Так что кто из двух лидеров лучше вписывается в unix-way -- это ещё можно поспорить. (:

Как выяснили выше, готовые vcs сами по себе практически равноценны по функциональным характеристикам. Но одна из них — практически монолит, а вторая собрана из конструктора, который доступен и пользователю. Вот эта самая дополнительная доступность конструктора и есть плюс, с моей т.з.

А с моей дополнительная простота в данном случае важнее дополнительной гибкости. Как видишь, всё субъективно. (:

Можешь назвать _широко распространённые_ причины одновременного использования двух vcs для одного и того же кода?

Конечно. Коммит в репозиторий cvcs требует соблюдения определенных правил, иногда относительно трудоемких. Использование локальной dvcs позволяет наслаждаться всеми прелестями быстрого vcs без административного геморроя, пока не вылепится нечто, которое можно закоммитить. И да, центральный репозиторий может быть далеко и медленно.

Из централизованных vcs сейчас svn + cvs покрывают, думаю, примерно 99%. А с ними обеими, насколько я помню, mercurial подружить можно. Кстати, сейчас вспомнил: вроде бы где-то недавно читал, что и в git тоже можно напрямую пушить. Так что вообще из распространённых остаётся под вопросом только базар, да и то не факт: я просто не интересовался этим вопросом.

[watashiwa_daredeska]

А с моей дополнительная простота в данном случае важнее дополнительной гибкости. Как видишь, всё субъективно. (:

Даже спорить не буду. Столько копиев уже об это сломано было :)

Из централизованных vcs сейчас svn + cvs покрывают, думаю, примерно 99%.

Не буду врать на счет процентов, но в моей практике всякие Perforce и Rational ClearCase занимают существенно более 1%. И в случае отсутствия готового гейта git, как конструктор, думаю, проще привязать к конкретным условиям, нежели mercurial.

[t.t]

Почему же не совсем? Думаю, очень многим от dvcs нужна только dvcs, а не ещё один конструктор. В частности, именно потому, что unix сам является конструктором, а dvcs во многих схемах лишь один из винтиков внутри него; который должен "делать одну задачу, но делать её хорошо". Так что кто из двух лидеров лучше вписывается в unix-way -- это ещё можно поспорить. (:

Ну, это всё равно, что называть юниксвейным аутпост, в котором и антитроян, и фаерволл, и сетевой монитор, и т.д., исходя из того, что он выполняет одну задачу - защиту компьютера.

В unix-way под "одной задачей" подразумевается одна низкоуровневая задача. А vcs - задача достаточно высокоуровневая.

Некорректный пример. Попробуй разбить задачу контроля версий на подзадачи, аналогичные тем, которые ты объединил в "защиту компьютера".

Вообще, мне ближе другой пример: почта. И тут мне кажется, что mercurial скорее можно сравнить с одним из звеньев связки fetchmail + procmail + exim, чем со всей связкой в целом.

[t.t]

А с моей дополнительная простота в данном случае важнее дополнительной гибкости. Как видишь, всё субъективно. (:

Даже спорить не буду. Столько копиев уже об это сломано было

Я о том и говорю, что спорить здесь не о чем.

Из централизованных vcs сейчас svn + cvs покрывают, думаю, примерно 99%.

Не буду врать на счет процентов, но в моей практике всякие Perforce и Rational ClearCase занимают существенно более 1%. И в случае отсутствия готового гейта git, как конструктор, думаю, проще привязать к конкретным условиям, нежели mercurial.

Хорошо, 99% это я, пожалуй, хватил. Это скорее применительно к FOSS. Если же "вообще", то всяко больше половины будет. Т.е. всё остальное (меньшая часть) на "второе по значимости" не тянет.

[deadhead]

вроде бы где-то недавно читал, что и в git тоже можно напрямую пушить

ага, Hg-Git ;-)

[sash-kan]

В описаниях git: "в svn и других scm такие-то и такие-то недостатки; в git всё не так".

Тихон. боюсь, это была именно эта цитата:

Different from SVN

It is important to note that this is very different from most SCM systems that you may be familiar with. Subversion, CVS, Perforce, Mercurial and the like all use Delta Storage systems - they store the differences between one commit and the next. Git does not do this - it stores a snapshot of what all the files in your project look like in this tree structure each time you commit. This is a very important concept to understand when using Git.

да, это кардинальное отличие архитектуры git-а.

от приведенной тобой ссылки там мало что отличалось бы: архитектура действительно очень похожа.

«басня про git» написана именно про git. на основании только неё, я, заглянув в каталог .git, смогу написать в несколько строк на баше базовую реализацию функций commit, checkout, branch. аналогичное действие для mercurial-а по этому описанию я сделать не смогу.

вроде бы где-то недавно читал, что и в git тоже можно напрямую пушить.

конечно, можно. архитектура-то примитивная. реализация взаимодействия с git-ом — дело простое.

[/dev/random]

fetchmail + procmail + exim

Да, этот пример корректнее.

Вообще, мне ближе другой пример: почта. И тут мне кажется, что mercurial скорее можно сравнить с одним из звеньев связки fetchmail + procmail + exim, чем со всей связкой в целом.

Хранение данных с адресацией по хешу - это отдельная задача. См, например, aMule. Кстати, неплохая идея - попробовать связать git и kad network )).
Организация этих файлов в дерево - задача тоже отдельная, но, в принципе, включаемая в первую.
Переключение между версиями, ветки, слияние и т.д. - по сути, отдельные задачи. Единственное, что их связывает - это взаимодействие с первой задачей. Если выделить её в отдельную программу, то и решения этих задач могут существовать, распространяться и использоваться отдельно друг от друга.
Ну и, наконец, взаимодействие репозиториев. Очевидно, что это вообще не задача vcs, а скорее таких программ, как ssh. Но здесь, правда, git и hg одинаково дали маху.

[t.t]

В описаниях git: "в svn и других scm такие-то и такие-то недостатки; в git всё не так".

Тихон. боюсь, это была именно эта цитата:

Это был собирательный образ. Большей частью таких цитат, гед в описанных механизмах между git и mercurial ан практике нет вообще никакой разницы.

от приведенной тобой ссылки там мало что отличалось бы: архитектура действительно очень похожа.

«басня про git» написана именно про git. на основании только неё, я, заглянув в каталог .git, смогу написать в несколько строк на баше базовую реализацию функций commit, checkout, branch. аналогичное действие для mercurial-а по этому описанию я сделать не смогу.

Сходу вопрос: а зачем?.. Противопоставление готовой dvcs и инструмента для создания собственной dvcs ты снова проигнорировал. (:

вроде бы где-то недавно читал, что и в git тоже можно напрямую пушить.

конечно, можно. архитектура-то примитивная. реализация взаимодействия с git-ом — дело простое.

По архитектуре я тоже писал уже более чем неоднократно. И тоже был проигнорирован.

Вообще, мне ближе другой пример: почта. И тут мне кажется, что mercurial скорее можно сравнить с одним из звеньев связки fetchmail + procmail + exim, чем со всей связкой в целом.

Хранение данных с адресацией по хешу - это отдельная задача. См, например, aMule. Кстати, неплохая идея - попробовать связать git и kad network )).
Организация этих файлов в дерево - задача тоже отдельная, но, в принципе, включаемая в первую.
Переключение между версиями, ветки, слияние и т.д. - по сути, отдельные задачи. Единственное, что их связывает - это взаимодействие с первой задачей. Если выделить её в отдельную программу, то и решения этих задач могут существовать, распространяться и использоваться отдельно друг от друга.

Я ждал такого ответа. Но на мой взгляд тут уместнее другая параллель: функционал procmail тоже можно полностью переписать на shell + coreutils + grep + sed.

Ну и, наконец, взаимодействие репозиториев. Очевидно, что это вообще не задача vcs, а скорее таких программ, как ssh. Но здесь, правда, git и hg одинаково дали маху.

Строго говоря, hg clone != scp. Насчёт git не знаю.

[t.t]

Опять-таки, в первую очередь мне хотелось бы услышать ответ вот на это:

не хочешь согласиться с тезисом "каждому своё".

так хочется воскликнуть: «ссылки в студию!»

Прошу, вот это было одно из раскрытий тезиса "каждому своё":

Другими словами, я утверждаю, что все преимущества обеих наиболее популярных dvcs друг над другом субъективны и контекстно-зависимы.

не согласен.

Разъясни пожалуйста, как согласие с этим тезисом слепить с выраженным в этой цитате несогласием. Пока для меня это выглядит так, что ты сам себе противоречишь.

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

[/dev/random]

функционал procmail тоже можно полностью переписать на shell + coreutils + grep + sed.

"Переписать" и "логически разделить" - это немного разные вещи.

[sash-kan]

Опять-таки, в первую очередь мне хотелось бы услышать ответ вот на это:

я уже отвечал:

я в предыдущем посте неправильно сформулировал. слово «это» требует расшифровки:
от контекста зависит лишь, считать ли это те или иные преимущества того или иного vcs плюсом или минусом.

это было как раз по поводу этого поста (я внёс исправления):

Другими словами, я утверждаю, что все преимущества обеих наиболее популярных dvcs друг над другом субъективны и контекстно-зависимы.

не согласен. скорость, простота архитектуры, функциональность, простота расширения — это не субъективно.
от контекста зависит лишь, считать ли это те или иные преимущества того или иного vcs плюсом или минусом.

надеюсь, теперь наконец понятно, что не согласен я с «субъективны», но согласен с «контекстно-зависимы».

[t.t]

функционал procmail тоже можно полностью переписать на shell + coreutils + grep + sed.

"Переписать" и "логически разделить" - это немного разные вещи.

На данных конкретных примерах не вижу разницы. Поясни.

[/dev/random]

"Переписать" и "логически разделить" - это немного разные вещи.

На данных конкретных примерах не вижу разницы. Поясни.

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

[t.t]

Опять-таки, в первую очередь мне хотелось бы услышать ответ вот на это:

я уже отвечал:

я в предыдущем посте неправильно сформулировал. слово «это» требует расшифровки:
от контекста зависит лишь, считать ли это те или иные преимущества того или иного vcs плюсом или минусом.

это было как раз по поводу этого поста (я внёс исправления):

Другими словами, я утверждаю, что все преимущества обеих наиболее популярных dvcs друг над другом субъективны и контекстно-зависимы.

не согласен. скорость, простота архитектуры, функциональность, простота расширения — это не субъективно.
от контекста зависит лишь, считать ли это те или иные преимущества того или иного vcs плюсом или минусом.

надеюсь, теперь наконец понятно, что не согласен я с «субъективны», но согласен с «контекстно-зависимы».

По прежнему ничего не понятно. (:

С одной стороны, я вижу здесь явные нарушения логики: как можно называть нечто "преимуществами", если то, "считать ли их плюсом или минусом", "зависит от контекста"??? (Этот вопрос я уже задавал, но ответа не увидел.)

С другой стороны, конкретно по пунктам (что тоже уже писалось большей частью):
1. скорость: разница столь мала и неповсеместна, столь зависима от контекста измерений, что преимуществом она может являться лишь в очень малом проценте случаев;
2. простота архитектуры: так и не увидел ни единого весомого аргумента, что архитектура git принципиально проще архитектуры mercurial, хотя просил об этом раз шесть как минимум;
3. функциональность: устал повторять, что во многих случаях функциональность git _избыточна_, т.е. является не преимуществом, а недостатком;
4. простота расширения: далеко не всегда расширение нужно как таковое, и уж тем более далеко не всегда важна его простота;
5. с другой стороны, у mercurial тоже есть преимущества, навскидку:
а) простота (лёгкость) изучения;
б) простота (стройность) устройства: например (то, о чём уже говорили), наличие одновременно index-а, полок и веток, мною воспринимается как _каша_; и если полки можно и не использовать, то от индекса по большому счёту никуда не денешься: он заложен в архитектуру.

Да и сам тот факт, что меня тебе не удаётся переубедить, даже после подключения к теме других наших коллег, выбравших git, разве не свидетельствует о субъективности само по себе? (:

[watashiwa_daredeska]

На данных конкретных примерах не вижу разницы. Поясни.

Из fetchmail, procmail, MTA и MDA — это элементы конструктора. У меня из этих элементов собрана почтовая система для персональной машины, но можно собрать и что-то другое, путём сшивки элементов конструктора shell-скриптами. Так и с git — в основе лежит конструктор, который можно shell-скриптами сшивать (поначалу так и было сделано, ЕМНИП), просто одна из наиболее востребованных конструкций уже собрана разработчиками для пользователя заранее, но ничто не мешает собрать другую — конструктор-то остался.

[t.t]

"Переписать" и "логически разделить" - это немного разные вещи.

На данных конкретных примерах не вижу разницы. Поясни.

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

Многие procmail-фильтры влёгкую "выстраиваются линейно" из более простых утилит.

[/dev/random]

Многие procmail-фильтры влёгкую "выстраиваются линейно" из более простых утилит.

Многие, но, увы, не все.

[t.t]

На данных конкретных примерах не вижу разницы. Поясни.

Из fetchmail, procmail, MTA и MDA — это элементы конструктора. У меня из этих элементов собрана почтовая система для персональной машины, но можно собрать и что-то другое, путём сшивки элементов конструктора shell-скриптами. Так и с git — в основе лежит конструктор, который можно shell-скриптами сшивать (поначалу так и было сделано, ЕМНИП), просто одна из наиболее востребованных конструкций уже собрана разработчиками для пользователя заранее, но ничто не мешает собрать другую — конструктор-то остался.

Если так рассуждать, то любой shell-скрипт -- это уже не unix-way. (: Или по крайней мере, любая программа на си, функционал которой можно реализовать shell-скриптом.

Многие procmail-фильтры влёгкую "выстраиваются линейно" из более простых утилит.

Многие, но, увы, не все.

(: Хорошо, другой пример: dpkg это unix-way?

[watashiwa_daredeska]

Если так рассуждать, то любой shell-скрипт -- это уже не unix-way.

Всё познаётся в сравнении. У большинства команд coreutils есть выполняемая ими функция, но нет «сферы применения» — это всего лишь кирпичики для конструирования чего-то большего. Так вот, dvcs — это та самая «сфера применения», изменить её практически нельзя. Конструктор же, лежащий в основе git, также не имеет «сферы применения», хотя обёртка в виде полноценной dvcs, уже имеет. Изменить сферу применения dvcs git так же тяжело, как и любой другой, но воспользоваться конструктором git для совершенно других целей гораздо легче.

[t.t]

Если так рассуждать, то любой shell-скрипт -- это уже не unix-way.

Всё познаётся в сравнении. У большинства команд coreutils есть выполняемая ими функция, но нет «сферы применения» — это всего лишь кирпичики для конструирования чего-то большего. Так вот, dvcs — это та самая «сфера применения», изменить её практически нельзя. Конструктор же, лежащий в основе git, также не имеет «сферы применения», хотя обёртка в виде полноценной dvcs, уже имеет. Изменить сферу применения dvcs git так же тяжело, как и любой другой, но воспользоваться конструктором git для совершенно других целей гораздо легче.

На мой взгляд, контроль версий (а dvcs это лишь лучшее на данный момент его воплощение, не более) -- это примерно в той же степени "сфера применения", что, скажем, восьмеричное представление текстового потока или его сортировка; ну или уж diff по крайней мере.

[/dev/random]

(: Хорошо, другой пример: dpkg это unix-way?

К сожалению, с Debian я мало знаком, и не интересовался, как реализован dpkg. В принципе, с учётом простоты структуры формата deb, его можно реализовать в качестве простенькой обёртки вокруг tar и других. Если это так и сделано, то вполне юниксвейно.

[watashiwa_daredeska]

На мой взгляд, контроль версий (а dvcs это лишь лучшее на данный момент его воплощение, не более) -- это примерно в той же степени "сфера применения", что, скажем, восьмеричное представление текстового потока или его сортировка; ну или уж diff по крайней мере.

На мой взгляд — нет, это более комплексная штука. Как, например, package management. В этом плане мне нравится APT/dpkg — весь поток данных, в общем, открыт, можно вмешаться, подправить что-нибудь, не прибегая к hexedit (ну, разве что deb-пакеты чем-то незначительно отличаются от ar-архивов, так что file их различает). В принципе, можно построить аналогичную систему на shell, элементами конструктора являются, в этом случае, стандартные утилиты.

[t.t]

На мой взгляд, контроль версий (а dvcs это лишь лучшее на данный момент его воплощение, не более) -- это примерно в той же степени "сфера применения", что, скажем, восьмеричное представление текстового потока или его сортировка; ну или уж diff по крайней мере.

На мой взгляд — нет, это более комплексная штука. Как, например, package management. В этом плане мне нравится APT/dpkg — весь поток данных, в общем, открыт, можно вмешаться, подправить что-нибудь, не прибегая к hexedit (ну, разве что deb-пакеты чем-то незначительно отличаются от ar-архивов, так что file их различает). В принципе, можно построить аналогичную систему на shell, элементами конструктора являются, в этом случае, стандартные утилиты.

Вот. К этому я и подводил своим вопросом к /dev/random. Функционал dpkg пишется на shell слёту. Тем не менее, написан dpkg всё-таки на си (сейчас; изначально был на перле). Но ты ведь не будешь спорить, что dpkg -- это unix-way?

[sash-kan]

С одной стороны, я вижу здесь явные нарушения логики: как можно называть нечто "преимуществами", если то, "считать ли их плюсом или минусом", "зависит от контекста"??? (Этот вопрос я уже задавал, но ответа не увидел.)

вот уж не думал, что тут что-то непонятное.
домохозяйка предпочтёт ручуню автоматическую коробку передач, автогонщик — только ручную.
пояснять дальше?

upd. поправил ошибку: s/ручную/автоматическую/