GNOME перешел на Subversion

Ну дык KDE тоже типа занимает место. Трафик нынче дёшев

> Учитесь!;)

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

Разумеется, самим себе! Сам себя не поздравишь - ...;)

Только морд нормальных нет для mercurial. Да и к остальным нет.

По сравнению с xtla они отдыхают. DVC тоже не дотягивает пока :(

> > А какая из DVCS выглядит "похожей" на сvs?

> BitKeeper, Mercurial.

> Git не видел, а Arch (tla) действительно ужас, явно не для людей писался, поэтому может он технически и лучше, а пользоваться им невозможно.

BitKeeper выглядит "похожей" на cvs? Это сколько надо принять, чтобы такое сказать? :) Впрочем с сией проприетарщиной лишь по спецификациям знаком.

Работа с tla уж поболее похожей на работу с cvs будет. Тот же workflow пока разрабатываешь ветку, "update", "add", "commit", "changes", "diff". А если учесть все опциональные вкусности вроде "undo", "redo", branch/merge и с несколько десятков других полезных комманд, то более удобной утилиты для разработки из коммандной строки трудно найти.

Git технически похуже arch будет (changesets не так чисто сделаны, нет file ids а следовательно и переименований и merge между независимыми проектами, нет namespaces, требует громаднейшего места на локальном диске), и по удобству тоже.

Ничего особо критичного против Bazaar и Mercurial не имею, кроме того, что на Python сделаны. Просто нет в них удобства и красоты Arch. Хотя на вкус и на цвет товарища, как известно, нет. :)

> (changesets не так чисто сделаны, нет file ids а следовательно и переименований и merge между независимыми проектами, нет namespaces

ИМХО, в Arch грязная реализация changeset'ов. Это не в упрек ему сказано - Arch был прорывной, революционной системой. Но он был первым, и остальные научились на его опыте - в основном тому, что в таком виде changeset'ы не нужны.

> нет file ids а следовательно и переименований и merge между независимыми проектами

Линус считает отсуствие file ids фичей, и приводит веские доводы.

> нет namespaces

Это не нужно. Вообще все эти категории, бранчи, архивы (что там еще есть?) - это настолько overkill, что просто тоска.

> требует громаднейшего места на локальном диске

Это не так. Первые версии - да, требовали. Но уже года полтора есть packed repositories (или как там оно называется :)), которые являются самым компактным представлением из всех открытых SCM, да и закрытых, наверное.

> и по удобству тоже.

Истинная правда. Пользоваться этим могут только роботы.

> Ничего особо критичного против Bazaar и Mercurial не имею, кроме того, что на Python сделаны.

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

> Просто нет в них удобства и красоты Arch. Хотя на вкус и на цвет товарища, как известно, нет. :)

Ты второй человек после Тома Лорда, который назвал Arch красивым и удобным :)

> что в таком виде changeset'ы не нужны

С ума сошёл? Именно в таком виде и нужны. Имеется в виду логический и функциональный вид, а не какая-либо полу-текстово/полу-бинарная имплементация. Супер удобно работать с changeset-ами, разве что кто-то больше cvs ничего осилить не может. А смотреть на них через archeye (на GTK, или может быть через emacs, не пробовал) - одно заглядение. Тут тебе среди их преимуществ: "undo", "redo"; "changes"; cherry-picking; прислать много-файловый патч с полной информацией как обычный tar.gz, так что даже не имея tla можно в крайнем случае использовать untar+patch; синхронизировать проекты, у которых лишь 20% файлов общие, да ещё и с совсем другими именами, как ни фантастично слышится, но это работает; сохранять права файлов и директорий, работать на полную с директориями и символическими линками как единицами. Что может быть удобнее changeset от arch, все якобы улучшения они от лукавого. :-)

> git packed repositories

Не хочу я на всех рабочих машинах хранить репозитории, пакнутые или нет, а хочу рабочие деревья проектов держать. А репозитории хочу делать независимыми (то есть, локальными иль ремотными, как мне в том или ином конкретном случае удобно, посему darcs, git и от них зависимые не подходят, иногда "упаси-бог" и централизованно хочется работать, что с arch очень даже возможно при умелых руках).

> Линус считает отсуствие file ids фичей, и приводит веские доводы.

На меня эти "веские" доводы не действуют. Глупо возводить содержимое файла в ранг святого и работать лишь с ним и его хэшами. Ввести такую единицу проекта как файл (у которого в разное время может быть разное имя и родительская директория) сама природа unix велела. Ни svn ни git этого не позволяют - на свалку. :)

>> что в таком виде changeset'ы не нужны

>С ума сошёл? Именно в таком виде и нужны.

Современные системы (Mercurial, Git, Bzr, Monotone) их не используют - и вполне себе неплохо работают.

>> git packed repositories

>Не хочу я на всех рабочих машинах хранить репозитории, пакнутые или нет, а хочу рабочие деревья проектов держать. А репозитории хочу делать независимыми (то есть, локальными иль ремотными, как мне в том или ином конкретном случае удобно

По поводу того, что представление репозитория Git - самое компактное, возражений нет? Отлично. Насчет остального - работы в этом направлении ведутся, Mercurial уже это умеет, Git тоже вот-вот научится. В Monotone это может быть реализовано тривиально.

> иногда "упаси-бог" и централизованно хочется работать

А можешь привести пример, когда это _необходимо_? Не считая случая "репозиторий занимает 100Г" - на практике таких проектов немного.

> Глупо возводить содержимое файла в ранг святого и работать лишь с ним и его хэшами. Ввести такую единицу проекта как файл (у которого в разное время может быть разное имя и родительская директория) сама природа unix велела. Ни svn ни git этого не позволяют - на свалку. :)

Зашибись довод. "Глупо возводить идентификатор файла в ранг святого, и работать с ним, а не его содержимым и хэшами" - ИМХО, не менее логично звучит :D Угрюмый факт жизни - Mercurial, Git, Monotone, SVN не используют идентификаторов, и тем не менее отлично работают.

> вполне себе неплохо работают

> работы в этом направлении ведутся

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

> Угрюмый факт жизни - Mercurial, Git, Monotone, SVN не используют идентификаторов, и тем не менее отлично работают.

Так и cvs тоже отлично работает. Стоило ли так потеть, не получив ничего принципиально лучшего? Только вот не всем, как ни странно, такой урезанной функциональности достаточно.

>> вполне себе неплохо работают

>> работы в этом направлении ведутся

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

А почему "переоткрывают Arch"? С таким же успехом можно сказать, что эта фишка - переоткрытие CVS. Или SVN. Кстати, случая, где _необходима_ централизованная разработка, ты не привел.

>> Угрюмый факт жизни - Mercurial, Git, Monotone, SVN не используют идентификаторов, и тем не менее отлично работают.

>Так и cvs тоже отлично работает.

Смешно.

> Стоило ли так потеть, не получив ничего принципиально лучшего?

Принципиально лучшего чем CVS? Все эти системы именно принципиально лучше. Чем Arch? Жизнь уже рассудила, что Arch ушел, а его место заняли Git,Mercurial и Bzr. Том Лорд сам признал превосходство нового поколения VCS. Да в мире свободного софта и не уходят "принципиально лучшие" продукты в небытие так, как Arch. Даже когд Arch был _единственной_ из свободных VCS, его мало кто использовал - а сейчас он просто доживает свое.

> Кстати, случая, где _необходима_ централизованная разработка, ты не привел.

Я много чего не привёл, потому как приводить тебе очевидные вещи просто нет смысла. В большинстве проектов мира, кроме тех у кого один незаменимый мейнтейнер, доступ записи к mainline (из которого делаются официальные снепшоты и релизы) должен быть у нескольких разработчиков, а то вдруг главный заболеет. Я уж не говорю о компаниях, где часто незаменимых разработчиков вовсе нет, люди уходят часто (сами или нет).

> Том Лорд сам признал превосходство нового поколения VCS.

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

> его мало кто использовал - а сейчас он просто доживает свое

А-га, и cvs тоже просто доживает свое, и все другие проекты тоже. Давай ты будешь о себе липь говорить, а не о том, чего ты не знаешь (где именно и что используется). Я использую на всех рабочих машинах. Просто копирую туда бинарник tla и работаю, в отличии от... Все твои доводы о каких-то якобы недостатках или неудобстве абсолютно надуманы. Ну не все осилили, согласен, включая Линуса, так он часто был недальновидным (включая историю с биткипером), ничего нового.

>> его мало кто использовал - а сейчас он просто доживает свое

>А-га, и cvs тоже просто доживает свое

Ну приведи пример, где _новый_ проект начинает использовать CVS. Она доживает свое там, где людям слишком хлопотно или просто лень ее менять. А переходов с CVS - довольно много (хотя переходили в основном на SVN, но сути это не меняет). Новые же проекты выбирают SVN, Git, Mercurial. Кто выбирает Arch? Никто, это и называется "доживает". Почти все, кто отметился в разработке Arch - теперь разрабатывают Bzr.

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

Только и ты - не говори о том, чего не знаешь. Arch (в реинкарнации larch) был реализован в 2002-м году, потом переписан на Си и стал tla в 2003-м. Сейчас уже 2007-й, и прогресс ни на секунду не останавливался - в областb DVCS работало много умных парней. И если ты считаешь Тома гением, который всё предвидел и сделал уже тогда - то это _ты_ не знаешь, о чем говоришь.

> Я использую на всех рабочих машинах. Просто копирую туда бинарник tla и работаю, в отличии от...

Да не вопрос - пользуйся. Много людей до сих пор добровольно пользуется SCCS и RCS. Это значит одно из двух: 1) их задачи достаточно просты 2) они ССЗБ, потому что лишают себя удобства современных VCS.

> Все твои доводы о каких-то якобы недостатках или неудобстве абсолютно надуманы.

Ну да, и Том Лорд хотел разработать revc (он же Arch 2.0) с git-like storage backend от того, что в Arch нет никаких недостатков.

> Ну не все осилили, согласен, включая Линуса

Том неоднократно пиарил Arch на LKML - и он не прижился. Так что это не только Линус.

> Ну да, и Том Лорд хотел разработать revc (он же Arch 2.0) с git-like storage backend от того, что в Arch нет никаких недостатков.

Ты предположил, что я боготворю Тома Лорда, это неверно, я оцениваю технические идеи. То была вынужденная мера; как известно, против лома (в виде десятков рьяных последователей Линуса, сказал биткипер, будет, сказал гит, будет) нет приёма. Arch 1 хорош и его историю я хорошо знаю. Если добавить те или иные оптимизации и сделать множество незначительных улучшений в интерфейсе не меняя концепции, то я за. Никто не собирался в Arch 2 урезать такие аттрибуты как file ids и dumb server, ну разве что подправить core namespace, и я был бы первым противником урезания функциональности. Так что это не аргумент того, что git хорош; он плох, если сравнивать с arch, и я приводил выше аргументы. Сравнивать же с питоновскими наработками, где главенствует принцип "worse is better" не хочется.

>> Ну да, и Том Лорд хотел разработать revc (он же Arch 2.0) с git-like storage backend от того, что в Arch нет никаких недостатков.

> Ты предположил, что я боготворю Тома Лорда, это неверно, я оцениваю технические идеи.

Да не предполагал я такого. Я говорил именно о технических идеях - если автор хотел практически переписать программу, значит, ее технические идеи нуждались как минимум в модернизации, причем он признал это год назад.

> никто не собирался в Arch 2 урезать такие аттрибуты как file ids и dumb server, ну разве что подправить core namespace, и я был бы первым противником урезания функциональности.

file ids - это только средство достижения цели - хорошей поддержки переименований. Если эта цель достигается другими средствами (как в Monotone, Mercurial, Git) - какая тебе разница? А насчет правки namespace и урезания неиспользуемой функциональности - ну так это одни из целей Bzr.

> это не аргумент того, что git хорош; он плох, если сравнивать с arch, и я приводил выше аргументы.

Про отсуствие file ids? Git достигает поддержки rename другими средствами.

> Cравнивать же с питоновскими наработками, где главенствует принцип "worse is better" не хочется.

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

А насчет "worse is better" - это сказал Габриель о Unix. Или ты пользуешься виндой? ;)

> file ids - это только средство достижения цели - хорошей поддержки переименований. Если эта цель достигается другими средствами (как в Monotone, Mercurial, Git) - какая тебе разница?

В том-то и дело, что не только и не столько для переименования. Ты никогда не мерджил между независимыми проектами? Я мержил. Имеется себе ветка mylib со своими исходниками, тестами, документацией. Беру и в проект myapp добавляю исходники с теми же file ids, но возможно с другими именами и локациями внутри дерева проекта. Возможно тесты тоже добавляю, адаптируя к стилю большого проекта; но документация не нужна, не добавляю, или добавляю, но в последующих ревизиях стираю. Всё, могу теперь делать merge (синхронизацию) между любыми ревизиями mylib и myapp, хоть они и не ветки одного проекта, а вовсе разными группами разрабатываются. file ids - незаменимая штука, и никакие трюки не помогут, когда дизайн дырявый.

Блин, ну это ж надо абсолютно ничего не понимать, чтобы агититовать отсутствие file ids, якобы потому как можно и без них всё точно узнать. Ничего подобного. Не верь тем, кто тебе запудривает голову, говоря, что можно. Даже если пройдёшься по всей истории всех веток на всех девелоперских машинах (что может занять дни, и что абсолютно излишне при наличии ids), всё равно не узнаешь, стёр ли кто-то файл и потом его же передобавил или это он совсем новый файл добавил просто с тем же именем.

> Судя по этим словам, ни одной из них ты не пользовался. Кстати - в Bzr не только работают практически все разработчики Arch, но и имеются так дорогие тебе file ids.

Почему ты решил, что я не знаю? Покаместь ни одно твоё предположение обо мне не оправдалось. Я не стал бы называть 4-ёх кодеров, у которых baz выкидывал core dump через раз, хорошими разработчиками, да ещё и "практически всеми". От перехода на Питон их код не может чудесным образом преобразиться, а вот наоборот может. Потому как лучше уж core dump, чем неправильная работа RevCS.

> А насчет "worse is better" - это сказал Габриель о Unix. Или ты пользуешься виндой? ;)

Ну и логика. Мало ли кто что и когда сболтнул. Да и перевёртываешь ты всё с ног на голову, как раз всё наоборот. Gabriel argues that "Worse is better" [early unix] produces more successful software than the "MIT approach" [late unix]. :)

> В том-то и дело, что не только и не столько для переименования. Ты никогда не мерджил между независимыми проектами? ... Всё, могу теперь делать merge (синхронизацию) между любыми ревизиями mylib и myapp, хоть они и не ветки одного проекта, а вовсе разными группами разрабатываются. file ids - незаменимая штука, и никакие трюки не помогут, когда дизайн дырявый.

Ты _точно_ не пользовался по крайней мере Mercurial - в нем вполне возможно слияние независимых проектов, и когда исправят ошибки при работе с переименованиями, всё можно будет делать именно так, как ты описал. Хотя рекомендованным способом будет наверняка использование расширения forest - это типа build-config в Arch. Насчет Git - он, я так думаю, всё описанное тобой тоже умеет, по крайней мере мержит независимые проекты без проблем. И заметь - никаких file ids.

> Судя по этим словам, ни одной из них ты не пользовался. Кстати - в Bzr не только работают практически все разработчики Arch, но и имеются так дорогие тебе file ids.

>Почему ты решил, что я не знаю? Покаместь ни одно твоё предположение обо мне не оправдалось.

Я решил что ты "не пользовался" - если это предположение не оправдалось, то так и скажи: мол, пользовался и Git, и Mercurial, и Bzr.

> Я не стал бы называть 4-ёх кодеров, у которых baz выкидывал core dump через раз, хорошими разработчиками

Я не называл их "хорошими разработчиками" (хотя они такие и есть). Насчет core dump'ов - ну у меня и tla выкидывал их, и говорил "botched invariant". И что? Любому софту надо созреть. А насчет "кодеры" vs "разрадотчики" - ты не читал девелоперский список рассылки Arch в 2003-м году.

Ладно, замнем. Почему-то у Arch всегда было странное свойство - долго им пользоваться могли только фоннатеги, а вменяемые люди либо начинали свои проекта (ArX, Baz), либо сваливали на другие системы. Хочешь пользоваться Arch и чувствовать себя элитой - пожалуйста.

Напоследок:

> Блин, ну это ж надо абсолютно ничего не понимать, чтобы агититовать отсутствие file ids

Блин, ну это ж надо абсолютно не уметь читать, чтобы не увидеть, что в Bzr есть file ids :)

>> А насчет "worse is better" - это сказал Габриель о Unix. Или ты пользуешься виндой? ;)

>Ну и логика.

Причем здесь логика? Это голый факт, я просто привел источник цитаты.

>Да и перевёртываешь ты всё с ног на голову, как раз всё наоборот. Gabriel argues that "Worse is better" [early unix] produces more successful software than the "MIT approach" [late unix].

И что же я перевернул? Фраза _была_ сказана _именно_ о UNIX. А без "early UNIX" не было бы "late UNIX".

> и когда исправят ошибки при работе с переименованиями

> думаю, всё описанное тобой тоже умеет - никаких file ids

И как можно с тобой после этого дискутировать? Это теоретически нерешаемая проблема, без file ids. Всё-таки промыли тебе мозги. Разве что изобрести миелафон, который будет мысли разработчика задним ходом читать, что именно он 3 года назад имел в виду, стирая один файл и добавляя другой - переименование или просто создание нового файла. Либо сделать какой-то эвристический костыль, который не работает в 90% моих случаев (когда нет общей fork-point). Хочешь работать с недееспособными костылями в виде mercurial, git и подобного - на здоровье. Я же буду удобно работать с чистым дизайном arch-1, не допускающем разночтений, что очень критично при синхронизации. (При том, что и остальные пункты дизайна и осуществления тоже обставляют твои системы.)

Ещё раз, с надеждой, что на ты не безнадёжен. Если я имею два независимых проекта. И в одном проекте файл conf/httpd.conf имеет id1, а в другом проекте файл conf/httpd.conf имеет id2, а файл newconf/httpd.conf имеет id1 (по разным причинам, например кто-то когда-то сделал переименование директории conv в newconv, или просто решил использовать конфигурацию, похожую на ту из независимого первого проекта), то синхронизация файлов проектов будет идеальной в системах с file ids, в остальных же системах не заработает вовсе или заработает неправильно, хоть ты тресни, и какие костыли не навесь.

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

> ты не читал девелоперский список рассылки Arch в 2003-м году

Опять (уже четрвёртое в треде по счёту) предположение обо мне, которое неверно. Ну и самомнение телепата у тебя.

> Блин, ну это ж надо абсолютно не уметь читать, чтобы не увидеть, что в Bzr есть file ids :)

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

> Я решил что ты "не пользовался" - если это предположение не оправдалось, то так и скажи: мол, пользовался и Git, и Mercurial, и Bzr.

Реально для себя не пользовался (хоть и знаю большинство их под-комманд и что конкретно они делают). По той же причине, по которой я не пользуюсь, скажем Windows или MacOS - в этом нет никакой необходимости. Это не мешает мне постоянно отвечать на вопросы сотрудников об этих OS, потому как некоторые могут прекрасно знать систему, не работая в ней, а некоторые могут и за 10 лет использования не узнать её как следует.

> Это теоретически нерешаемая проблема, без file ids.

Историю переименований отследить - нерешаемая проблема? Ну-ну.

> что именно он 3 года назад имел в виду, стирая один файл и добавляя другой - переименование или просто создание нового файла.

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

>Это большой вопрос, кто из нас слеп; я же писал в том сообщении на которое ты отвечаешь, что знаю про bzr.

В том сообщении ты написал о baz, _не_ о bzr.

>> то так и скажи: мол, пользовался и Git, и Mercurial, и Bzr.

> Реально для себя не пользовался ... некоторые могут прекрасно знать систему, не работая в ней

И эти люди называеют _меня_ телепатом 8/

> Историю переименований отследить - нерешаемая проблема? Ну-ну.

Перечитай повнимательней. Нету у этих двух веток общей истории, совсем нет. Просто добавил под-директорию из одного проекта в другой, и начал делать "tla mv", "tla rm", edit, как мне угодно.

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

Само собой, я же именно так и говорю. Только этого абсолютно недостаточно. Даже если и есть общая история, то её проверка займёт дни, а имея ids никакого ворошения истории не требуется вовсе. А уж если и общей истории нет, то вообще никак. Впрочем об этом я говорил ещё 5-ю сообщениями выше, но ты упорно не вникаешь.

> В том сообщении ты написал о baz, _не_ о bzr.

Этим я дал понять, что те, кого ты называешь разработчиками tla, перешедшими в bzr, на самом деле перешли туда не сразу, а проявили уже себя в baz, и большого моего доверия к ним нет.

> И эти люди называеют _меня_ телепатом.

Неа, я называю тебя неудавшимся телепатом. :-)

>> Историю переименований отследить - нерешаемая проблема? Ну-ну.

>Перечитай повнимательней. Нету у этих двух веток общей истории, совсем нет

Я так и понял (где я говорил, что есть/нужна общая история?).

> Просто добавил под-директорию из одного проекта в другой, и начал делать "tla mv", "tla rm", edit, как мне угодно.

Уффф. В последний раз, в надежде на то, что ты всё-таки не безнадежен... Вот как это делается в Mercurial: pull из репозитория "другого" проекта в репозиторий "этого". Затем переносишь все файлы "другого" проекта в подкаталог (например) vendor/другой/, коммитишь. Дальше объединяешь получившуюся ветку с основной, и всё - на основной ветке у тебя в каталоге "vendor/другой/" лежит чужой проект: делай с ним то, что захочешь - "hg mv", "hg rm", edit, как тебе угодно. Думаю, что тоже самое относится и к Git.

ЗАМЕТЬ - в Mercurial вышеописанная процедура не является рекомендованной, так же, как в Arch не является (по крайней мере, не являлась) рекомендованной процедура, описанная тобой. В Arch для объединения в одном дереве разных проектов рекомендовалось делать build-config, а в Mercurial будет рекомендован (я так думаю :)) hgforest.

> Я так и понял (где я говорил, что есть/нужна общая история?).

В том же сообщении двумя строками ниже и говоришь:

> pull из репозитория "другого" проекта в репозиторий "этого", переносишь, коммитишь.

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

А теперь, внимание вопрос. Как без file ids даже в твоём примере делать cherry picking? Рассмотри ревизии перед и после твоей операции в одном проекте и в другом. Рассмотри также мою ветку (у нас с тобой общий fork-point в ревизии X). Что будет, если я независимо от тебя тоже начну из того же или другого проекта заимствовать файлы, с теми же или другими именами, и потом (или перед этим) мы будем меж собой синхронироваться. Ты быстро поймёшь, что без file ids никуда. Конечно можно через зад симулировать file ids, исследуя историю всех веток в мире вглубь и вширь, например просчитывать, что conf/httpd.conf это на самом деле tailgunner-prj-123:add=misc/httpd.conf:mv=conf/httpd.conf и по каким-то признакам определять, что это тот же файл, что и mihalych-prj-100:pull=gosha-prj-66=template.conf:mv=templates/example.conf. Но это настолько неэффективно (и по времени сбора информации о каждом файле и по надёжности), что просто жуть... Это всё вместо того, чтобы просто с каждым файлом хранить его уникальный id и не создавать проблемы на свою голову.

> В Arch для объединения в одном дереве разных проектов рекомендовалось делать build-config

Это какой умник такое рекомендует? Никакие атомные операции производить нельзя, configs - это просто так, фикция. Надо выбирать, то что для данного проекта вернее (главенствует либа или аппликация или обе). Уж намного лучше тогда просто на одном уровне держать зависимые проекты и делать символические линки охватывающие один уровень вне дерева. Кроме того, как раз work-flow со смешиванием файлов из разных линий в одном дереве (не обязательно по отдельным под-директориям) и атомный commit всего дерева (в разные проекты) был предложен года 3 назад, но это очень сложно осуществить на деле, чтобы удобно было пользоваться. Покаместь и средствами arch-1 можно справиться с большинством закрутастых задач.

>> pull из репозитория "другого" проекта в репозиторий "этого", переносишь, коммитишь.

>Вот ты и создал общую историю проектов

У тебя несколько необычное понимание термина "общая история проектов".

> Конечно можно через зад симулировать file ids, исследуя историю всех веток в мире вглубь и вширь

Не "всех веток в мире", а только нужных. А вширь - вообще не надо. Насчет "через жопу" - это к Arch относится? Потому что в Mercurial и Git эта информация всегда доступна в удобном для использования виде.

>> В Arch для объединения в одном дереве разных проектов рекомендовалось делать build-config

> Это какой умник такое рекомендует?

Том Лорд. Если бы архивы девелоперского листа были все в одном месте, я бы тебе даже ссылку дал. Но то, что build-config активно используется, и так видно и в Arch'евой Wiki, и в архивах последних лет.

> > Конечно можно через зад симулировать file ids, исследуя историю всех веток в мире вглубь и вширь

> Не "всех веток в мире", а только нужных. А вширь - вообще не надо.

Вот ты и показываешь, что не врубаешься. Именно что вширь и надо тоже, причём искать надо в неизвестных для твоего дерева местах (то есть просто невозможно в случае с дизайном git). Иначе при более сложной топологии веток и/или cherrypicking не сможешь понять, что файл в дереве и в патче тот же самый, просто у тебя не вся информация о нём есть. Имея же id моментально понятно, какие файлы в патче соответствуют каким файлам в дереве.

> build-config активно используется

Используется (сам использую в одном проекте), но есть лучше решение с символическими линками меж деревьев.

>> Не "всех веток в мире", а только нужных. А вширь - вообще не надо.

> Вот ты и показываешь, что не врубаешься. Именно что вширь и надо тоже

Но "историю всех веток в мире" просматривать всё же не надо? Отлично.

> причём искать надо в неизвестных для твоего дерева местах

Этого просто не понял. В операции merge по определению участвуют 3 дерева - общий предок, исходное, целевое. История переименований позволяет элементарно найти, какие файлы исходного соответствуют каким файлам целевого.

> то есть просто невозможно в случае с дизайном git

Git тоже умеет отслеживать историю переименований, хотя не всегда со 100% надежностью.

> Git тоже умеет отслеживать историю переименований, хотя не всегда со 100% надежностью.

Ты говоришь о реснице в глазу, не замечая в нём бревна. В системах без file ids просто напрочь невозможны некоторые методологии как: независимое добавление в разных ветках файла с тем же id (потому как это один логический файл), частичное применение патчей некой ветки (cherrypicking), стирание части истории (потому как слишком громоздкая стала за месяцы интенсивной работы) и многое другое. То есть это всё в урезаном виде возможно, но тогда теряется всякая связь между файлами. И тут ни mercurial, ни git тебе не помогут. Плохой дизайн не позволяет.

> В системах без file ids просто напрочь невозможны некоторые методологии как: независимое добавление в разных ветках файла с тем же id

:D "Методология", да? Как громко сказано. Лично мне за несколько лет такое ни разу не понадобилось. Да, нигде, кроме Arch (и Bzr), такое невозможно, ну и что? Никогда не встречал жалоб на это.

> частичное применение патчей некой ветки (cherrypicking)

Это возможно - я даже объяснял, как.

> стирание части истории (потому как слишком громоздкая стала за месяцы интенсивной работы)

Думаю, что это возможно в Bzr, но пойнт не в этом - если ты стираешь историю ветки, которая смержена в другую, ты ССЗБ (проверено на практике - мы потеряли часть истории при преобразовании SVN -> Mercurial). Если ветка никуда не смержена, то ее можно удалить и в Mercurial, и в Git.

> и многое другое.

Если тебе не трудно, скажи - что именно?

> > частичное применение патчей некой ветки (cherrypicking)

> Это возможно - я даже объяснял, как.

Это возможно, не теряя связи между файлами? Даже если в пропущенных патчах имеется стирание и добавление файла (по имени, не id), или переименование? Я же говорю, если хранить в дереве полную информацию о всех патчах (в прошлом и будущем) всех веток в мире (что естественно никак, без центрального регистрия всех веток и машины времени), то тогда возможно, иначе нет. И мы не углублялись ещё в особые проблемы нетривиальных топологий, когда много зависимых веток хаотичым образом синхронизируются меж собой.

> Если тебе не трудно, скажи - что именно?

Я приводил выше реальные примеры. Конечно у каждого свои требования. Просто arch-1 практически идеально ложится под мои нужды, а другие системы нет. Я реально использую и свойства file ids для синхронизации большого проекта с маленькими, и свойства dumb server для оптимального выбора места репозитория (на своей машине или нет) очень удобно.

git и mercurial были бы слишком громоздкими для меня и неудобными (оперируют с ничего не говорящими длинными идентификаторами, я привык уже к супер-удобному namespace; нет возможности задать репозиторий и определить доступ к нему). Да и во многих мелочах нельзя повторить мой work-flow. У bzr свои проблемы, которые мы можем рассмотреть, было бы время. Вот и выходит для меня, что лучше arch-1 ни по удобству, ни по функциональности ничего не придумано.

>> Это возможно - я даже объяснял, как.

> Это возможно, не теряя связи между файлами? Даже если в пропущенных патчах имеется стирание и добавление файла (по имени, не id), или переименование?

При переименовании - да, при стирании+добавлении - вряд ли.

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

В репозитории нужно хранить 2 (два) дерева - источник патча и приемник. _И ВСЁ_.

> Просто arch-1 практически идеально ложится под мои нужды, а другие системы нет. Я реально использую и свойства file ids для синхронизации большого проекта с маленькими, и свойства dumb server для оптимального выбора места репозитория

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

> git и mercurial были бы слишком громоздкими для меня и неудобными (оперируют с ничего не говорящими длинными идентификаторами

Mercurial умеет оперировать и с короткими идентификаторами, и с именами патчей (плагин mq). И Git, и Mercurial поддерживают символические имена бранчей и теги.

По-моему, здесь:

> ну разве что подправить core namespace

> я привык уже к супер-удобному namespace

есть некоторое противоречие.

> При переименовании - да, при стирании+добавлении - вряд ли.

Я имел ввиду, что изменения содежимого происходит всегда тоже, где-то в пропущенных патчах. Так что без ids связь между файлами теряется и при обычном переименовании + изменение. К тому же для меня эвристическое связи, когда сравнивается содержимое является не фичей git, а его багом. Сколько раз мне приходилось, имея файлы tests/feature-1, tests/feature-2, tests/feature-3, tests/feature-4, вставлять новый файл tests/feature-3 и пододвигать старые два файла на позиции 4 и 5 (tla mv tests/feature-4 tests/feature-5; tla mv tests/feature-3 tests/feature-4). Для разноразия также подправим маленько старый feature-3. Теперь попытаемся этот простой описанный патч, содержащий всего лишь add+mv+mv+edit применить в паралельной ветке, где ещё нет, скажем, файла feature-4 и/или feature-3. В git и mercurial всё сделается неправильно (если не на этом шаге, то на следущем, когда применятся наконец патчи добавляющие feature-4 и т.д.), хоть ты разьбейся, потому как просто не будет доставать информации. А в системе с file ids, хоть и тоже при cherrypicking не будет доставать информации, всё сделается правильно. А ведь в жизни бывают и посложнее ситуации (swap двух или нескольки файлов/директорий), когда mercurial запутается в два счёта, не говоря уже о git.

> В репозитории нужно хранить 2 (два) дерева - источник патча и приемник. _И ВСЁ_.

Ох, устал я повторять. Ты уж поверь мне, что это не верно. Расмотри несколько веток, где каждая содержит некоторые, но далеко не все патчи других, причём разные subsets, и попытайся составить математическую модель merge.

> Достигнуть тех же целей другими средствами с меньшими затратами сил - можно.

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

> По-моему, здесь есть некоторое противоречие:

> > ну разве что подправить core namespace

> > я привык уже к супер-удобному namespace

Будет ли противоречие или нет - зависит от дизайна. Трудно говорить о том чего нет. storage namespace может строится на случайных идентификаторах, но конечный пользователь может, например, продолжать видеть namespace схожий с arch-1.