Вышел Mercurial 1.9

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

В предложенном тобой варианте придётся контролировать не только скрипт, но и дерево каталогов (binaries/).

Зачем?

> ты забыл написать, что для получения сорцов тут аж 3 команды — pull, fetch и checkout ... и вот так во всём ...

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

pull - вытащит изменения и смержит текущую ветку. Это хорошо, если хочется механизм, подобный mercurial (или для тех, кто только начинает осваивать git, чтобы не усложнять).

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

checkout - переходит на определенную ревизию, непонятно, к чему она здесь?

> Зачем?

А как? - /binaries должны храниться вне репозитория? Как я понял, gaga предлагает их хранить в репе.

Скажите, они читаемы?

нет :(. Внутрях всё страшно.

>Я работал и с git и с hg, мне hg больше нравится, раз в 5 больше...
Чем же ветки понравились больше?

> Внутрях всё страшно.

По-моему, ты преувеличиваешь. Соглашение о именах у Мэтта, конечно, своебразное, но к остальному какие претензии?

>chcp 65001

вай нот дефолт?

http://ru.wikipedia.org/wiki/Qt Оно конечно можно писать на Qt без GUI. Но я такого не видел. Кстати у них что обертки для файлового АПИ? Зачем?

> обертки для файлового АПИ? Зачем?

Для удобства. В том числе позволяют использовать кутэшную resource system.

>> chcp 65001

вай нот дефолт?

видимо, как всегда - для совместимости

> А как? - /binaries должны храниться вне репозитория? Как я понял, gaga предлагает их хранить в репе.

Зачем хранить в репозитории бинарники, полученные из стороннего кода, который находится в своих репозиториях? Какой смысл?

Логичнее хранить в репозитории скрипт, который создаст на устройстве файловую систему, соберёт бинарники и скопирует их на устройство.

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

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

>> команды типа clone, pull, commit, push и некоторых других достаточно просты, если не слишком залезать в дебри их параметров

ты забыл написать, что для получения сорцов тут аж 3 команды — pull, fetch и checkout ... и вот так во всём ...

Да и некоторые свойственные DVCS фичи наподобие отсутствия необходимости коннектиться к серверу почти на каждый чих весьма удобны.

так почему именно git ? hg умеет все тоже самое, но лишен его недостатков

А такого модуля под hg нет? https://github.com/apenwarr/git-subtree

А то очень надо, а в гит его включать не хотят :( Если похожее в hg появилось бы сильно бы спасло.

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

В двух местах поддерживать конечно не дело, тут надо думать. Можно сделать их вообще несвязанными, типа binaries/utils/cp -> target/usr/bin/cp, тут не знаю, надо думать для твоего случая.

В hg есть аналог submodules - subrepos.

В общем, каждому свое. Я бы не хранил выходную иерархию.

Во, может ты скажешь. Аналога: https://github.com/apenwarr/git-subtree в hg не появилось? А то, вроде как года 2 назад не было :(

По-моему, ты преувеличиваешь

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

Я попытался сделать экстеншн под свои нужды для меркуриала. Т.к. доков практически нет то пришлось лезть в сырцы. Например, посмотрел как устроен плагин pager или color. Это тихий ужас, имхо. И, главное, по-другому не вижу как сделать задуманно. Там очень много грустных вещей, например, подмена или враппинг встроенных комманд. Да и вообще архитектура странная.

Я скажу что я делал. Я попытался сделать так чтобы комманда hg status работала вместе с hgsubstate и показывала бы статус для всех репов сразу. Даже почти работало.

> Аналога: https://github.com/apenwarr/git-subtree в hg не появилось?

Если я правильно понимаю, это отчасти функциональность hg convert (когда надо разбить дерево), отчасти - обычный hg pull (для слияния).

> Я попытался сделать экстеншн под свои нужды для меркуриала. Т.к. доков практически нет то пришлось лезть в сырцы. Например, посмотрел как устроен плагин pager или color. Это тихий ужас, имхо. И, главное, по-другому не вижу как сделать задуманно. Там очень много грустных вещей, например, подмена или враппинг встроенных комманд. Да и вообще архитектура странная.

Улыбнуло. А питонщики это достоинством считают. И большинство задач так же архитектурно решаются.

О вкусах не спорят. Так что лучше эту тему замять.

Не знаю, честно говоря. Там ниже ответили про convert, может сработает.

>> Аналога: https://github.com/apenwarr/git-subtree в hg не появилось?

Если я правильно понимаю, это отчасти функциональность hg convert (когда надо разбить дерево), отчасти - обычный hg pull (для слияния).

Пока не понял. Что за зверь такой hg convert. Поэксперементирую вечером. Нужна возможность разрабатывать проект не задумываясь, где библиотека, а где программа. Периодически изменения в библиотеке заливать в ее основной репозитарий. Вытягивать от туда конечно то же.

> ты забыл написать, что для получения сорцов тут аж 3 команды — pull, fetch и checkout ... и вот так во всём ...

Ох-хо-хо... Кое-кто недокурил. Или перепил...

fetch - получение состояния ремоутного репозитория, без того, чтобы трогать твои ветки

merge - слияние текущей активной ветки [с указанной]

rebase - перенос коммитов текущей активной ветки в указанную точку графа коммитов

pull - суперпозиция fetch и merge (или fetch и rebase, если с соответствующим ключом)

checkout - приведение [части] рабочего дерева в соответствие с указанным состоянием репозитория.

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

> функциональность hg convert (когда надо разбить дерево)

Это односторонняя операция, т.е. только из большого repo можно выделить repo для subtree.

А там в обе стороны:

If the standalone library gets updated, you can

automatically merge the changes into your project; if you update the library inside your project, you can «split» the changes back out again and merge them back into the library project.

Если в subtree repo сделать изменения, то как потом из него перетащить эти изменения в основной repo, если hg будет выдавать, что эти два repo никак не связаны?

Улыбнуло

Что именно?

А питонщики это достоинством считают

что имеенно?

О вкусах не спорят

а о сотнях строк кода чтобы сделать простейший функционал спорят?

> Он сложен, ненадежен и туп.

По-моему, это то, чем выглядит git после svn. Команды svn после гита - образец однозначности, лаконичности и юниксвейности.

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

(Я svn 5 лет назад внедрил на работе. Начальство, которое очень хотело Microsoft SourceSafe, сначала сопротивлялось, потом согласилось, а когда пошли юниксовые проекты, выяснилось, что я был прав.)

> Всем выше высказавшимся на счёт «закопать SVN» желаю хотя бы один раз поработать с VSS.

Люто, бешено плюсую.

В hg есть одна команда pull которая может как скоблить так и не мерджить. Слово checkout сбивает с толку так как в других системах и него иной смысл.

> В hg есть одна команда pull которая может как скоблить так и не мерджить.

Равно как и git.

Слово checkout сбивает с толку так как в других системах и него иной смысл.

man ложные друзья переводчика.

У каждой системы своя терминология, как это можно всерьёз считать недостатком?

Итак, ещё высосанные из пальца аргументы будут?

> У каждой системы своя терминология, как это можно всерьёз считать недостатком?

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

> Если в subtree repo сделать изменения, то как потом из него перетащить эти изменения в основной repo, если hg будет выдавать, что эти два repo никак не связаны?

Двунаправленный обмен сделать, пожалуй, не удастся. Ты пользуешься этим git-subtree? У меня пара вопросов по его использованию.

> По-моему, это то, чем выглядит git после svn.

git ненадёжен по сравнению с svn? Лишь до тех пор, пока svn не потеряет пару-тройку коммитов, и ты случайно не обнаружишь это через полгода. git туп по сравнению с svn? Лишь до тех пор, пока не поймёшь, что СКВ — нечто большее, чем хранилище кода. А эффективность использования svn сети и дискового пространства — вообще образец для подражания.

Команды svn после гита - образец однозначности, лаконичности и юниксвейности.

Сделаю вид, что слова «юниксвейность» я не заметил. Конечно, команды svn — образец лаконичности. Чем же им ещё быть, если эта штука с корнями из 70-х ничего не умеет?

Вот меркуриал, кстати, в этом плане мне показался получше гита

потому что изображает из себя распределённый svn? Чтобы не травмировать психику иммигрантов.

поэтому последнее время я начал его ковырять, правда, не очень активно и пока «для себя»

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

ога, pull в git это fetch + checkout. что мешало им сделать ключ у fetch'а, чтобы не плодить лишнии сущности ?

>> У каждой системы своя терминология, как это можно всерьёз считать недостатком?

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

Терминология git специально придумана для того, чтобы быть удобной в контексте её использования. «Устоявшаяся» терминология — это та, что пришла из мира централизованных СКВ? Если да, то в этой теме она — offtopic.

pull в этом списке явно лишний, чую сделали его только потому, что во всех нормальных системах был pull, а в git'е вместо него был какой-то непонятный fetch

> «Устоявшаяся» терминология — это та, что пришла из мира централизованных СКВ?

Ты так говоришь, будто интерфейс распределенных СКВ обязательно придумать заново.

Я делаю это с помощью subrepos. То есть есть один большой мета-репозиторий и к нему в качестве subrepos подключены мелкие. Можно работать как со всем репозиторием сразу, так и с subrepos'ами по отдельности. Правда в этом есть недостаток — бывают одновременные изменения, которые затрагивают одновременно и библиотеку и программу, находящиеся в разных subrepo, обеспечить их атомарность таких изменений невозможно.

мне вот интересно, был же биткипер, которым линус пользовался несколько лет, почему нельзя было просто всё скопировать, нафига было изобретать свое, которое только хуже ?

> ога, pull в git это fetch + checkout. что мешало им сделать ключ у fetch'а, чтобы не плодить лишнии сущности ?

man git

NAME

git - the stupid content tracker

Изначально git — набор скриптов для управления содержимым файлов. Если следовать первоначальной идее, из этих скриптов можно сделать СКВ, а можно что-то ещё для своих нужд.

Команды git делятся на две категории — низкоуровневые, которые и делают непосредственно всю работу (любимый здесь некоторыми принцип «программы, которые делают одну вещь, но делают её хорошо»), и высокоуровневый интерфейс к ним. Заскриптовав низкоуровневые команды, получим средство для решения своих специфичных задач. По-видимому, это ты знаешь без меня.

man git-pull

git pull runs git fetch with the given parameters and calls git merge to merge the retrieved branch heads into the current branch. With --rebase, it runs git rebase instead of git merge.

Сделать ключ у fetch'а им мешало то, что тебе может понадобиться твоя собственная реализация pull. Вот и всё.

>> «Устоявшаяся» терминология — это та, что пришла из мира централизованных СКВ?

Ты так говоришь, будто интерфейс распределенных СКВ обязательно придумать заново.

Модели работы изменились, логично пересмотреть старый интерфейс. Вообще, в век alias'ов, графических клиентов и интеграции со средами разработки это беспредментый разговор.

man git неадекватен. Например, по краткому описанию к git reset можно сделать вывод, что этой командой можно сбросить изменения _только_ _всего_ репозитория. Если в git есть разделение на низкоуровневые команды и высокоуровневые команды, то почему это не обозначено в мане?

> Ты пользуешься этим git-subtree?

Нет, я вообще git почти не использую (если только иногда что-то клонирую на посмотреть). Использую hg и subrepos, а с ними пока не все так гладко.

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

Subrepos как раз и обеспечивают атомартность на уровне «одного большого мета-репозитория». В .hgsubstate пишутся ревизии всех subrepos, только за этим «мета-репозиторием» тоже нужно следить и вовремя коммитить в него.

>> Ты так говоришь, будто интерфейс распределенных СКВ обязательно придумать заново.

Модели работы изменились, логично пересмотреть старый интерфейс.

Пересматривать? O_o Добавить в него clone, push и pull (как и сделал Mercurial).

> Использую hg и subrepos, а с ними пока не все так гладко.

А я вот начинаю думать, что что-то похожее на git-subtree - это даже лучше subrepos (для гомогенного Mercurial-окружения).

>> вот уже 8 лет (с 2001-го года

Ну и кто здесь слоупок? У анонимуса на дворе 2009-й год...

Да, машина времени сбоит иногда и в криокамере перебои с электроэнергией бывают. Но сути это не меняет — NT, для которой юникод является нативной кодировкой, на десктопы пришёл давным-давно (10 лет — не так мало даже по не-IT-шным меркам, для которых это вообще почти вечность), и нежелание некоторых разработчиков слезать с 8-битных антикварных кодировок либо понимать, что не во всём мире пользуются латиницей, является проблемой этих разработчиков, а не системы, в которой с юникодом всё в порядке. Кстати, я на 99.9% уверен, что не будь таких разработчиков, MS давно бы отказалась от DOS-овской cp866 в качестве дефолтной консольной кодировки в системах, где и DOS-а-то нет.

>По-моему, это то, чем выглядит git после svn. Команды svn после гита - образец однозначности, лаконичности и юниксвейности.

Простота svn, это следствие его примитивизма. зачем всякие там pull и push если никаких удаленных репов быть не может? Зачем помечать дифы ууидами, если есть центральное место и каждый коммит можно в нем нумеровать по порядку? и т.д.

> Простота svn, это следствие его примитивизма. зачем всякие там pull и push если никаких удаленных репов быть не может?

man svk. Распределенный и простой в использовании, как SVN.

Нет, fetch - очень даже понятный. Это простая в понимании операция (получить состояние удалённого репозитория), цель которой - дать разработчику возможность посмотреть, чем занимаются другие, без опасности как-либо затронуть собственные изменения.

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

С другой стороны, в условиях какого-нибудь проекта из двух разработчиков и двумя активными бранчами, master и stable, никто не мешает забыть о существовании fetch и пользоваться исключительно pull'ом (да ещё и настроить его на автоматический --rebase), чтобы типа, история была «красивая» и «линейная». Кому-то нравится поп, кому-то - попадья, а кому - и поповская дочка.

> По-моему, это то, чем выглядит git после svn

git после svn выглядит праздником (кроме докачки клонирования). да, git написан инопланетянакми, но это были умные и логичные инопланетяне.

А что вв привязвлись к VSS? Он давно похоронен МС, таперича там TFS вместо него (кактус сей не ел).

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