>[оверквотинг удален]
>>metadata just so you can work on a branch of src/bin/ls
>>or src/sys. Not being able to check out src/sys is apparently
>>a design feature. (For what its worth, I don't buy the
>>submodules thing. There's just too much to go wrong for things
>>getting out of sync with each other.)"
>
>Вот мне и интересно, почему:
>- говоря о когерентности, отказываются от единого дерева -- см. выше про
>организацию
> linux-kernel vs xorg; Ммм... может быть мы с вами понимаем разное под словами "единое дерево"? Я что-то не помню, чтобы FreeBSD собиралась отказываться от оного.
>- говоря о части репозитория, отказываются от git-submodule(1).
Хммм... Интересно, как это сообразуется со словами того же тов. Линуса (когда речь шла о KDE, а ведь имеющееся в KDE разделение даже ближе к тому, что "удобно" для git, чем во FreeBSD):
"So I'm hoping that if you guys are seriously considering git, you'd also split up the KDE repository so that it's not one single huge one, but with multiple smaller repositories (ie kdelibs might be one, and each major app would be its own)"
Надо разбираться...
>Если хочется coherent и шоб не out-of-sync -- ну так и держите
>одним деревом. Не думаю, что у тех, кому есть что
>сделать по ls.c, до сих пор 9600.
Ну и в чём тогда прелесть DVCS?
>Если же хочется частичности -- ну так это в обратную сторону.
>Бишь противоречивое целостности требование.
Видимо, возникло некоего непонимание... FreeBSD нужно дерево исходников, которое "одно для всех"; каждый отдельный коммит сразу доступен всем. Деление же на "части" - это совсем из другой оперы. Речь о том, чтобы, с одной стороны, была возможность работать с произвольной частью репозитория (обратите внимание: произвольной, а не предварительно заданной); с другой, чтобы репозиторий был один для всех.
Да, git можно использовать в таком варианте. Но это не его ниша. Зато SVN, выполняя те же самые (в заданных рамках!) функции, легче для мигрирования (я не проверял, но это даже вы сами подтверждаете).
>"I don't buy" -- перевожу: "не осилил". Что тоже вполне характерно,
>вместе с внутренней противоречивостью как аргументации, так и запросов многих вроде
>бы и матёрых бздишников.
Исходя из того, что я могу починить что-то в электрическом щитке, вряд ли я туда ещё раз полезу. Отсутствие уверенности в правильной оценке последствий, ИМХО, не есть большее зло, чем переоценка собственных умений, приводящая к различного рода (порой непоправимым) последствиям.
>DISCLAIMER: Я НЕ ПОЛЬЗОВАЛСЯ git-submodule(1) ДЛЯ ПРОЕКТОВ
А я попробую в следующем, который скоро буду поднимать... Там и посмотрим:).
>>Или эти доводы:
>
>*sigh*
>
>Половина -- "ну это не как git, но покатит". Естественно, после
>CVS и SVN сладок.
Дык хорошо же, не? Ну а про то, что "лучшее - враг хорошего", думаю, напоминать не стоит:).
>>* there are a huge bunch of tools out there to talk to svn.
>
>Перевожу: "мы предпочитаем жить вчерашним днём, поскольку ресурсов ловить журавлей, а тем
>более строить самолёты -- у нас тупо нет".
Ваша воля. Я предпочитаю переводы более близкие по смыслу:).
>>> И поток изменений *очень* мощный, при этом не спадает, а
>>>нарастает вполне стабильно.
>>То-то пишут, что разработчики Linux порой узнают о том, что релиз ядра
>>где-то там не собрался через несколько недель после релиза...
>
>Значит, так этот релиз (или такая комбинация кода, конфигурации и железа) был
>нужен на этом "где-то".
Интересно, а какого хрена тогда портировали, если всё равно даже за кодом никто не следит... Я понимаю, когда портирование помогает выявлять те или иные косяки. Но если ента хрень даже не компилируется, то, получается, никто такой цели и не ставил. То есть цель - поставить галочку "портировано", так, что ли?
>>>Во фре на сейчас наблюдаю относительно этого скорее застой. Так что
>>>конкуренция, боюсь, как раз слабоватая, что чревато. Возможно, те же
>>>HP это понимают, потому подбрасывают понемногу ресурсов :)
>>Интересно, зачем фирме вкладываться в загнивающий проект?..
>
>Не знаю. Одно из соображений -- шоб lkml не расслаблялся (это
>была бы вполне реальная проблема -- вспомните NT4).
Шоб LKML не расслаблялся, нужно чтобы конкуренция была сильная, логично? ;) Как же может загнивающий проект составлять сильную конкуренцию? Он, по определению, наоборот, должен составлять всё более слабую.
>Ещё совсем не загнивающий, но выбор опять централизованной SCM -- шаг в
>этом направлении.
Для вас всеобщий переход на DVCS - это будущее, для меня - мода, для кого-то ещё - несбыточная фантазия. :)
