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

[drBatty]

Да, и ещё. В противовес упоминавшемуся здесь свойству git иметь более компактные репозитории, нужно упомянуть о том, что у mercurial более компактные бандлы. Что из этих двух фактов важнее, опять-таки, каждый выбирает сам.

я знал об этом, но, интересно - насколько? ИМХО все эти погони за копейками не стоят того...
А вот бандлы важны если за них платить реальные копейки (например я часто синхронизируюсь по GPRS).

[sash-kan]

Жаль, что дискуссия так внезапно прекртилась

затерялась в текучке.
продолжаем.

Если же использовать схему с отдельными ветками, то такой риск не может возникнуть в принципе.

честное слово, не понимаю, как наличие веток/полок/index-ов/чего_угодно может помешать любой из описанных ситуаций:

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

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

?

Огрубляя: есть два инструмента (в общем-то, произвольных), один из которых превосходит по функционалу второй. Если человек считает первый более удобным, то очевидно, что второй для него будет недостаточным (и наоборот: если более удобен второй, то первый избыточен). Видимо, я неправильно понял, что ты считаешь гитовский инструмент из твоего примера более удобным.

тут, imho, приложима стандартная ситуация: если предполагается, что инструментом будут пользоваться в основном люди несведущие, предпочтительнее будет инструмент с минимальными возможностями настройки (в частности, чтобы было меньше возможностей «поломать»).
т.е., огрубляя в свою очередь, я считаю git более подходящим для людей «сведущих».

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

примерно те же, что и от одновременного наличия на военной базе как баллистических ракет, так и перочинных ножиков.

[sash-kan]

в git появились аналоги hg incoming/outgoing?

есть прямые эмуляции этих команд. и есть (и всегда были) близкие аналоги:
http://stackoverflow.com/questions/231211/...ocal-and-remote

[t.t]

Если же использовать схему с отдельными ветками, то такой риск не может возникнуть в принципе.

честное слово, не понимаю, как наличие веток/полок/index-ов/чего_угодно может помешать любой из описанных ситуаций:

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

Очень просто: сначала ответвляешься, потом устраняешь.

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

?

Уже в этой ситуации, пожалуй не может. Может в предшествующей ей: когда я правлю файл и тестирую по ходу, я могу предварительно ответвиться и все "сомнительные" правки коммитить в боковую ветку -- отдельными коммитами. При такой схеме описанная тобой ситуация сводится к предыдущей задаче.

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

Огрубляя: есть два инструмента (в общем-то, произвольных), один из которых превосходит по функционалу второй. Если человек считает первый более удобным, то очевидно, что второй для него будет недостаточным (и наоборот: если более удобен второй, то первый избыточен). Видимо, я неправильно понял, что ты считаешь гитовский инструмент из твоего примера более удобным.

тут, imho, приложима стандартная ситуация: если предполагается, что инструментом будут пользоваться в основном люди несведущие, предпочтительнее будет инструмент с минимальными возможностями настройки (в частности, чтобы было меньше возможностей «поломать»).
т.е., огрубляя в свою очередь, я считаю git более подходящим для людей «сведущих».

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

При выборе для себя я руководствовался своей привычкой избегать излишних сложностей. Многие из сложностей (читай: возможностей -- это взаимосвязано) гита _мне лично_ кажутся излишними.

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

примерно те же, что и от одновременного наличия на военной базе как баллистических ракет, так и перочинных ножиков.

Некорректный пример: ракеты и ножички по сфере применения вообще не пересекаются. Если сравнить, скажем, с наличием в личном арсенале казака короткой сабли и засапожного ножа (кривого кинжала), тогда могу согласиться, с некоторой натяжкой.

[t.t]

в git появились аналоги hg incoming/outgoing?

есть прямые эмуляции этих команд. и есть (и всегда были) близкие аналоги:
http://stackoverflow.com/questions/231211/...ocal-and-remote

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

[t.t]

Да, и ещё. В противовес упоминавшемуся здесь свойству git иметь более компактные репозитории, нужно упомянуть о том, что у mercurial более компактные бандлы. Что из этих двух фактов важнее, опять-таки, каждый выбирает сам.

я знал об этом, но, интересно - насколько? ИМХО все эти погони за копейками не стоят того...

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

А вот бандлы важны если за них платить реальные копейки (например я часто синхронизируюсь по GPRS).

Вот я и говорю: и здесь всё ситуативно. Можно представить и обратную ситуацию: коммитится всё только локально, а общий размер хранилища сравним с размером носителя. Но обе крайности не так уж часты, особенно если учесть, что различия, насколько мне известно, укладываются в 10-15% максимум.

[sash-kan]

Да, чуть больше движений, но зато в случае возникновения критической ситуации гораздо меньше головняка.

предлагаю оставить вопрос о самодисциплине и выбранном стиле разработки на усмотрение самого разработчика. ведь для кого-то «головняком» может быть и постоянное насилие над собой (которое ты называешь «хорошим стилем работы с dvcs»). (улыбка)
в том случае, конечно, если стиль не регулируется корпоративными стандартами и за спиной у каждого программиста не стоит персональный менеджер с розгой.
в своём личном «хозяйстве» (working_copy/index-е/полках/ветках) программист, imho, может делать так, как ему удобнее. а вот на-гора, в общий репозиторий (общие ветки) ему, конечно, следует выдавать только отборную руду. каким именно способом он этого добьётся (используя технические возможности vcs, или лишь методом самодисциплинирования) — imho, не столь важно.

Некорректный пример

ок. согласен на саблю и кривой кинжал.

Описанный сценарий, который был всегда, я бы назвал скорее обходным манёвром, чем близким аналогом.

ну а я бы лично именно те скриптики и назвал обходным манёвром.
а заложенный изначально принцип «fetch отдельно, merge отдельно, а pull = fetch+merge», который как раз и позволяет «заглянуть» в чужой репозиторий, не сливая его коммиты со своими локальными, я бы назвал именно «нужным решением» (хорошо-хорошо, «близким аналогом»).

[t.t]

Да, чуть больше движений, но зато в случае возникновения критической ситуации гораздо меньше головняка.

предлагаю оставить вопрос о самодисциплине и выбранном стиле разработки на усмотрение самого разработчика. ведь для кого-то «головняком» может быть и постоянное насилие над собой (которое ты называешь «хорошим стилем работы с dvcs»). (улыбка)
в том случае, конечно, если стиль не регулируется корпоративными стандартами и за спиной у каждого программиста не стоит персональный менеджер с розгой.
в своём личном «хозяйстве» (working_copy/index-е/полках/ветках) программист, imho, может делать так, как ему удобнее. а вот на-гора, в общий репозиторий (общие ветки) ему, конечно, следует выдавать только отборную руду. каким именно способом он этого добьётся (используя технические возможности vcs, или лишь методом самодисциплинирования) — imho, не столь важно.

А я изначально сказал, что всё сугубо индивидуально в этом выборе (между git и hg). (; Стиль использования -- тоже ведь вещь сугубо личная, потому я и не делал специальной оговорки, что тот стиль, который я называю хорошим, кому другому может и не подойти. Насчёт насилия над личностью -- вообще вопрос спорный: недавно в "программах" drBatty как раз спрашивал, как автоматизировать коммиты при каждой успешной сборке. И сам же предложил наилучший вариант: с помощью мейкфайла. Тогда вручную останется только переключаться между ветками, а это нужно будет делать не чаще, чем в твоей схеме оперировать с полками/индексом. Да, немного в другие моменты (чуть более "на опережение), но это уже и есть вопрос исключительно личных предпочтений. Мне игра на опережение подходит больше, т.к. иначе я вечно что-то забываю.

Некорректный пример

ок. согласен на саблю и кривой кинжал.

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

Описанный сценарий, который был всегда, я бы назвал скорее обходным манёвром, чем близким аналогом.

ну а я бы лично именно те скриптики и назвал обходным манёвром.
а заложенный изначально принцип «fetch отдельно, merge отдельно, а pull = fetch+merge», который как раз и позволяет «заглянуть» в чужой репозиторий, не сливая его коммиты со своими локальными, я бы назвал именно «нужным решением» (хорошо-хорошо, «близким аналогом»).

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

[sash-kan]

в твоей схеме оперировать с полками/индексом.

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

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

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

[t.t]

в твоей схеме оперировать с полками/индексом.

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

А мне как раз показалось, что от недопонимания мы избавились. Я и не говорил, что ты противопоставляешь индекс и полки веткам -- скорее это я противопоставляю. Если быть точным, то я говорю, что для тех случаев, которые ты привёл в качестве примеров использования индекса, _мне_ удобнее использовать ветки; и соответственно, что я не вижу причин, по которым индекс или полки _для меня_ могут оказаться востребованы.

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

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

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

[t.t]

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

Другими словами, я утверждаю, что все преимущества обеих наиболее популярных dvcs друг над другом субъективны и контекстно-зависимы. И что выбор между ними нужно делать исключительно исходя из специфики применения и личных предпочтений. Опровержений этим утверждениям я пока не услышал.

[sash-kan]

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

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

[t.t]

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

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

По какому уже кругу?..

скорость

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

простота архитектуры

Не увидел здесь ссылки на объяснение, чем она проще. Подчёркиваю: не насколько проста сама по себе, а в чём проще, чем у hg. Т.к. там она тоже проста.

функциональность

По приведенным примерам из нашей дискуссии следует, что в зависимости от личных предпочтений, а также уровня компетентности людей в команде она может быть избыточной. В некоторых случаях (в частности, недостаточной компетентности) эта избыточность объективно вредна.

простота расширения

1. Чем же оно проще?
2. Не всегда оно нужно.

[sash-kan]

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

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

Не увидел здесь ссылки на объяснение, чем она проще. Подчёркиваю: не насколько проста сама по себе, а в чём проще, чем у hg. Т.к. там она тоже проста.

не увидел нигде в интернете описания архитектуры hg. ссылку на «напальцевое» описание архитектуры git-а я приводил.

По приведенным примерам из нашей дискуссии следует, что в зависимости от личных предпочтений, а также уровня компетентности людей в команде она может быть избыточной. В некоторых случаях (в частности, недостаточной компетентности) эта избыточность объективно вредна.

2. Не всегда оно нужно.

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

1. Чем же оно проще?

например, тем, что git — это конструктор.
в руках оказываются все низкоуровневые кубики:
$ ls /usr/lib/git-core/ | wc -l
139

[t.t]

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

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

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

Не увидел здесь ссылки на объяснение, чем она проще. Подчёркиваю: не насколько проста сама по себе, а в чём проще, чем у hg. Т.к. там она тоже проста.

не увидел нигде в интернете описания архитектуры hg. ссылку на «напальцевое» описание архитектуры git-а я приводил.

Не увидел в этом описании почти ничего, что не подошло бы и к архитектуре mercurial. Конечно, некоторая разница есть, в частности, в формате хранения отдельных файлов; но к архитектуре эта разница не имеет никакого отношения. И это я тоже уже писал. (:

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

не увидел нигде в интернете описания архитектуры hg.

Не увидел? Или не захотел увидеть? (: Оно лежит на самом видном месте: http://mercurial.selenic.com/wiki/Repository#Structure

По приведенным примерам из нашей дискуссии следует, что в зависимости от личных предпочтений, а также уровня компетентности людей в команде она может быть избыточной. В некоторых случаях (в частности, недостаточной компетентности) эта избыточность объективно вредна.

2. Не всегда оно нужно.

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

(: "Считать ли _преимущества_ _плюсом_ или _минусом_" (: Какие-то странные преимущества, если это зависит от контекста, не находишь?

1. Чем же оно проще?

например, тем, что git — это конструктор.
в руках оказываются все низкоуровневые кубики:
$ ls /usr/lib/git-core/ | wc -l
139

Не путай расширяемость с перестраиванием. Высказывание "git это не столько готовая dvcs, сколько инструмент для создания вашей собственной dvcs" я тоже уже приводил. Далеко не всем это нужно (на мой взгляд, нужно лишь в очень редких отдельных случаях). К расширяемости это не имеет никакого отношения.

Сначала пеняешь меркуриалу, что многий дополнительный функционал реализован в виде расширений, не все из которых входят в комплект, -- а потом обвиняешь в недостаточной расширяемости. (:

[t.t]

Позволю себе привести небольшую цитату из сравнения с git на сайте mercurial:

Mercurial has always focused more on interface aspects, which made it originally easier to learn. In comparison to Git, a shallower understanding is required to operate with Mercurial in a useful manner. In the long run, such encapsulation has given Mercurial the false appearance of being less powerful and featureful than it really is.

Мой вольный перевод:

Mercurial всегда уделял больше внимания аспектам интерфейса, что сделало его изначально более лёгким для изучения. Для успешной работы с Mercurial, по сравнению с Git, не требуется столь глубокого понимания. В конце концов Mercurial стал из-за этого выглядеть менее мощным и функциональным, чем он есть на самом деле.

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

[sash-kan]

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

чёрт! я в этой теме без юмора не могу обходиться уже после первого ответа!

Не увидел? Или не захотел увидеть?

и это аналог описания, ссылку на которое я приводил??? смешно.

Какие-то странные преимущества, если это зависит от контекста, не находишь?

ну а это вот не я же написал:

По приведенным примерам из нашей дискуссии следует, что в зависимости от личных предпочтений, а также уровня компетентности людей в команде она может быть избыточной. В некоторых случаях (в частности, недостаточной компетентности) эта избыточность объективно вредна.

и я с тобой согласен: в одном контексте та же бОльшая функциональность — это плюс, в другом — минус. и наоборот. что не так?

К расширяемости это не имеет никакого отношения.

так-так-так. про эмуляторы incoming/outgoing напомнить? легко ли их было написать для git-а? imho — легко.
а легко ли будет написать эмуляторы этих функций для mercurial (представив на минуту, что этих функций нет)? будут ли они так же коротки?

Общее своё мнение об изложенных там вещах смогу сказать после того, как дочитаю.

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

[/dev/random]

сравнение с git

Мда. Прочитал 1.3. И они ещё утверждают, что для использования гидраргиума не нужно понимать "внутреннюю кухню".

[t.t]

сравнение с git

Мда. Прочитал 1.3. И они ещё утверждают, что для использования гидраргиума не нужно понимать "внутреннюю кухню".

Правильно утверждают. Во-первых, те тонкости, о которых там говорится, совершенно не обязательно понимать для работы с тегами. А во-вторых, теги тоже далеко не всегда необходимы для работы с mecrurial; зачастую достаточно именованых веток.

[t.t]

чёрт! я в этой теме без юмора не могу обходиться уже после первого ответа!

Надо ли это понимать так, что все твои ответы не следует принимать всерьёз? (: Если так, у меня больше нет вопросов.

и это аналог описания, ссылку на которое я приводил??? смешно.

Ты не просил аналог. Ты просил описание архитектуры. Аналог искать не вижу смысла; почему -- см. выше, больше повторять не буду.

Какие-то странные преимущества, если это зависит от контекста, не находишь?

ну а это вот не я же написал:

По приведенным примерам из нашей дискуссии следует, что в зависимости от личных предпочтений, а также уровня компетентности людей в команде она может быть избыточной. В некоторых случаях (в частности, недостаточной компетентности) эта избыточность объективно вредна.

и я с тобой согласен: в одном контексте та же бОльшая функциональность — это плюс, в другом — минус. и наоборот. что не так?

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

К расширяемости это не имеет никакого отношения.

так-так-так. про эмуляторы incoming/outgoing напомнить? легко ли их было написать для git-а? imho — легко.
а легко ли будет написать эмуляторы этих функций для mercurial (представив на минуту, что этих функций нет)? будут ли они так же коротки?

Если я правильно помню (проверить сейчас не на чем), они будут почти идентичны по реализации.

Общее своё мнение об изложенных там вещах смогу сказать после того, как дочитаю.

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

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

Что касается общего впечатления от текста по приведенной выше ссылке, то его прочтение лишь утвердило меня в уже сформировавшейся позиции: каждому своё; а также подтвердило, что свой выбор я сделал правильно.

[drBatty]

Мда. Прочитал 1.3. И они ещё утверждают, что для использования гидраргиума не нужно понимать "внутреннюю кухню".

честно говоря, я так и не понял. но - использую ;)

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

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

[watashiwa_daredeska]

Ну хорошо, я готов поверить в то, что как самостоятельные VCS hg и git более-менее равноценны. Но вот такая штука, как использование VCS в паре с другой, например, SVN. Ну, вот ведётся проект в SVN и ничего тут не поделать. Для git есть инструменты, которые позволяют разработчику работать в git и взаимодействовать с основным репозиторием в SVN, CVS, arch и т.п. У нас, например, git используется в паре с perforce.

И для того, чтобы написать очередной гейт, не нужно глубоко копать — есть команды, позволяющие работать с репозиторием git на достаточно низком уровне. Можно хоть на shell писать.

[sash-kan]

Надо ли это понимать так, что все твои ответы не следует принимать всерьёз?

не так буквально, пожалуйста!

Аналог искать не вижу смысла

нет смысла его искать. нету его. не написан.

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

так хочется воскликнуть: «ссылки в студию!»
вот эта цитата разве не является изложением тезиса «каждому своё»:

тут, imho, приложима стандартная ситуация: если предполагается, что инструментом будут пользоваться в основном люди несведущие, предпочтительнее будет инструмент с минимальными возможностями настройки (в частности, чтобы было меньше возможностей «поломать»).
т.е., огрубляя в свою очередь, я считаю git более подходящим для людей «сведущих».

?
или мне, чтобы быть правильно понятому, следует чётко и недвусмысленно написать: «каждому своё»? ок, пишу чётко и недвусмысленно: каждому своё.

Если я правильно помню (проверить сейчас не на чем), они будут почти идентичны по реализации.

не будучи в ладах с питоном, не буду даже пытаться лезть во внутренности hg. но услышать хоть чей-нибудь отзыв о лёгкости/сложности этой реализации было бы весьма интересно. напоминаю: для git-а эта эмуляция написана в несколько строк на баше. существенных, по-моему, там всего три. остальное комментарии и красиво расписанные if-ы.

Я изначально искал и противоположную точку зрения тоже

https://git.wiki.kernel.org/index.php/GitComparison

[deadhead]

Но вот такая штука, как использование VCS в паре с другой, например, SVN.

Working with Subversion Repositories

[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.

Но вот такая штука, как использование VCS в паре с другой, например, SVN.

Working with Subversion Repositories

только с svn?

[t.t]

Ну хорошо, я готов поверить в то, что как самостоятельные VCS hg и git более-менее равноценны. Но вот такая штука, как использование VCS в паре с другой, например, SVN. Ну, вот ведётся проект в SVN и ничего тут не поделать. Для git есть инструменты, которые позволяют разработчику работать в git и взаимодействовать с основным репозиторием в SVN, CVS, arch и т.п. У нас, например, git используется в паре с perforce.

И для того, чтобы написать очередной гейт, не нужно глубоко копать — есть команды, позволяющие работать с репозиторием git на достаточно низком уровне. Можно хоть на shell писать.

Про svn уже ответили. Даже если насчёт остальных никак (что не факт; мне просто этот вопрос неинтересен, потому и искать не буду), то это лишь одно из локальных преимуществ git, которое вполне вписывается в озвученную мною концепцию. Думаю, ты не будешь спорить, что двустороннее взаимодействие нескольких разных vcs это далеко не самая востребованная задача.

[t.t]

У меня вообще возникло стойкое впечатление, что они стараются не замечать другие 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 и всем остальным". Собственно, ты приведенной цитатой лишний раз эту необъективность продемонстрировал. (:

[watashiwa_daredeska]

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

Не совсем так. Если смотреть с т.з. unix-way, то git — эффективный набор базовых инструментов, который позволяет делать многое. И даже не обязательно dvcs, т.к. в основе лежит content addressable file system.

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

Для dvcs, думаю, вторая по востребованности. Всё-таки, cvcs ещё не совсем ушли в прошлое и много где используются. Уверен, ещё долго будут использоваться. Даже если dvcs станут абсолютно доминирующими, необходимо будет взаимодействовать между разными dvcs.

[t.t]

Аналог искать не вижу смысла

нет смысла его искать. нету его. не написан.

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

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

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

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

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

не согласен.

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

Если я правильно помню (проверить сейчас не на чем), они будут почти идентичны по реализации.

не будучи в ладах с питоном, не буду даже пытаться лезть во внутренности hg. но услышать хоть чей-нибудь отзыв о лёгкости/сложности этой реализации было бы весьма интересно. напоминаю: для git-а эта эмуляция написана в несколько строк на баше. существенных, по-моему, там всего три. остальное комментарии и красиво расписанные if-ы.

Я тоже не так уж силён в питоне, да и не вижу смысла что-то здесь доказывать: принципиальная расширяемость и заточенность под расширение -- это разные вещи. Фразу про "инструмент для создания вашей собственной dvcs" устал цитировать; равно как и пояснять, что очень многим всё-же нужен только готовый инструмент, а не инструмент для создания инструмента.

Я изначально искал и противоположную точку зрения тоже

https://git.wiki.kernel.org/index.php/GitComparison

Прошу прощения, но это фуфло. Для начала снова сравнения git с svn, затем очередные бенчмарки, и сравнения "всего со всем". Всем этим барахлом гитовцы всех уже давно перекормили. Я говорил о кратком обозначении всех существенных разниц между git и mercurial; т.е. действительно аналог приведенного мною сравнения, но с другой стороны. Это действительно было бы интересно. Если что-то такое там упомянуто, буду благодарен за прямую ссылку.

[t.t]

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

Не совсем так. Если смотреть с т.з. unix-way, то git — эффективный набор базовых инструментов, который позволяет делать многое. И даже не обязательно dvcs, т.к. в основе лежит content addressable file system.

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

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

Для dvcs, думаю, вторая по востребованности. Всё-таки, cvcs ещё не совсем ушли в прошлое и много где используются. Уверен, ещё долго будут использоваться. Даже если dvcs станут абсолютно доминирующими, необходимо будет взаимодействовать между разными dvcs.

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