|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Aleksey I Zavilohin 2:5020/400 22 Aug 2002 15:26:15
To : Valentin Nechayev
Subject : Re: снова о процессе р азработки ядра
--------------------------------------------------------------------------------
**** Valentin Nechayev wrote:
> > AIZ>> нет - откуда ты возьмешь старые комментарии? 8-)
> > AIZ>> если ты внимательно следил за ядром линуксы то мог бы знать что
> > AIZ>> линус например не делал дифа между 1.2.x и 1.3.1 - а просто выложил
> > AIZ>> /полные/ исходники и сказал что типа вот новая версия поехали
> > AIZ>> отсюда 8-) (или это было между 1.0 и 1.1?)
> >> А кто мешает сделать diff между ними?
> AIZ> между чем и чем? Я ведь написал 1.2./x/ - т е не было точки форка 8-)
> Hе бывает. Точка форка где-то была. Он же не с нуля переписал, да-а?
да - где-то была - только где - никто не знает - а один финский оболтус
просто не помнит 8-)
> > AIZ>> это и есть плохо 8-) если б ты посмотрел - то увидел что у
> > AIZ>> биткипера есть понятие chageset - атомарное изменение (для которого
> > AIZ>> и делается описание), которое может затрагивать несколько файлов.
> >> В CVS его можно восстановить. Это гиморно при отсутствии правильного
> >> commitlog, но тем не менее восстановление делается элементарно (хотя и
> >> громоздко). Собрав изменения между статическими тегами, можно получить и
> >> сведенные воедино комплекты изменений между разными версиями, а не
> >> просто между голыми коммитами.
> AIZ> Обрисуй как? Если учесть что могут коммитить несколько человек в данный
> AIZ> момент и чисто теоретически могут зацепить один и тот же файл?
> По датам коммита. По commmitlog еще проще.
> А changeset'ы, перекрывающиеся на одном файле, ты все равно не
> выделишь иначе чем явным указанием списка атомарных коммитов, так
> что получается то же самое. И если изменения разных авторов
> законфликтуют - в смысле CVS'ового conflict - то тем более
> потребуется ручная работа.
> Bitkeeper'овские changesets - это метод переноса группы
> неконфликтующих изменений между репозиториями. Да, у него merge
> немного умнее. Hо все равно конфликт - особенно логический,
> неопределяемый мержилкой - надо ловить и отрабатывать руками.
дык ясно - никто еще не написал систему контроля на уровне логики работы
8-)) просто ты сам указал на все достоинства биткипера - некоторым они
существенны - вот и все
> >> Да, у CVS есть свои грабли - то же перемещение в дереве.
> >> Hо отказываться от любой, а тем более той, которую используют 99%
> >> народа от free source, системы трекинга и контроля версий... это уже
> >> не обоснованное решение, это очередные тараканы в голове. Как и во
> >> многом прочем у пана Торвальдса. Увы...
> AIZ> Заметь у человека были претензии - он их обрисовывал - и cvs мх /не/
> AIZ> решал. А то что пользовались 99% дык в какой-то момент времени теже 99%
> AIZ> дружно жевали sendmail, как впрочем счас те же 99% дружно жуют bind 8-/
> У BIND альтернативы нет, никакой (или DJB резолвер написал?
> А gethost*, getnameinfo, getaddrinfo он написал?)
> У намеда - может быть. Hо единственная распространенная альтернатива -
> не обладает качествами промышленного продукта, как и все у DJB.
ну такиже не единственная альтернатива 8-) (т е я согласен по поводу
резолвера) - но по поводу named несогласен 8-) кроме диджея есть еще
люди пишушие например maradns или powerdns
> Претензии Линуса росли из желания держать руку на кране, который он
> и закрывал когда его левой пятке хотелось. Hормальной общей работе
> CVS не мешала. Те же проблемы с перемещением каталогов во
еще раз - ему /мешало/ - дальше можно не читать. Однако ничт не
мешало/мешает вести сообществу отдельный проект или то, что человек
заботится об удостве /своей/ работы ты считаешь плохо?
> FreeBSD'шном репозитории решаются письмом repomeister'ам "сделайте
> cp в репозитории". Да, криво. Зато работает. И не требует от
> держателя крана работы иной кроме как чистить глюки коммиттеров
> (глюки на уровне репозитория, а не работы кода) которые бывают
> крайне редко - я разве что помню кривой импорт, который дал тыщу
> конфликтов и который решали откатом на бэкап.
Т е вместо девелопинга ты предлгаешь ему "глюки чистить"? 8-)
Судя по тому как у нас появляются стабильные релизы ему как раз до
лампочки что и как - для этого есть мантейнеры стабильных версий 8-)
> >> Свести предыдущие версии. Хотя бы между всеми зафиксированными ступенями
> >> (релизами, pre и прочими).
> >> И не надо говорить "вот ты и сделай".
> AIZ> Еще раз - откуда взять chagelog-и? Если для 2.-=последних/2.4 есть
> AIZ> что-то отдаленно их напоминающее то откуда взять их для более старых
> AIZ> версий? из пальца высасывать? - информация утерена по большому счету.
> Текст changelog'ов не нужен для начала. Хотя бы последовательность по
> версиям пусть будет. А changelog'и, если ты не заметил, писались прямо
> в файлах, так что их покажут diff'ы.
ну там писалось то что хотелось писать и где хотелось писаться - второй
нужность такой процедуры (импорта из ничего в биткипер) видимо стремится
к 0 - ибо VB нужен например diff а не cvs 8-) те кто считал что без cvs
жить не может - жили со своими cvs и раньше и сейчас живут с биткипером.
Проблема как уже говорлоь что человеку (Торвальдсу) хотелось уйти от
недостатоков cvs именно /для себя/.
> > >>> сколько лет талдонили Линусу "давайте запихнем ядро в систему
> > >>> контроля версий". Через сколько лет до него дошло?? Когда таки
> > >>> дошло, что мы в итоге получили?
> > AIZ>> ты читал почему он не хотел cvs?
> >> Читал. Бред это все. "Мне не нравится вот это, это и это, поэтому
> >> давайте вообще ничего пока не использовать". А огромный комплект
> >> преимуществ идет нафиг.
> AIZ> какие преимущества cvs перед bitkeeper-ом? Опиши - может их выложат на
> AIZ> www.bitkeeper.com 8-)
> Опять передергиваешь. Преимущества перед полным отсутствием системы.
> А преимущества CVS перед BitKeeper'ом общеизвестны:
> 1. Она - free source.
> 2. Она совместима с RCS, что позволяет RCS'овыми средствами производить
> диагностику и починку.
> Второе является и сильным недостатком - RCS сильно ограничена по
> функциональности в ряде вопросов. Первое - тоже, по мнению авторов
Hу уж прям 8-) приведи строки маквоя где-б он говорил что free source
мешает? Он просто говорил что нет аналогов ибо это работа нудная и
малоприятная.
> BitKeeper'а ;) Hо мне это не мешает, несмотря на нелюбовь к GPL.
> > AIZ>> или ты считаешь что cvs идеальна?
> >> Прекрати демагогию.
> >> Hету идеальных систем. У каждой свои недостатки.
> >> Hо и преимущества.
> AIZ> приведите - в разрезе спора. Без демагогии (одну бесплатность я знаю,
> AIZ> вторую гирокую распространенность и как следствие чуть большую
> AIZ> вылизанность в своем кругу задач тоже можете не приводить)
> Почему не приводить? Именно их и приведу.
> Да, с такой лицензией BK, как сейчас, это не дает существенного
> преимущества. А где гарантия, такая, какую дает GPL, что это не изменится?
> Я не демагогствую, я смещаю вопрос.
никакой - но у cvs был явный застой с идеями - и именно благодаря этому
появились arch/subversion
> > AIZ>> или как мне построить распределенный репозиторий?
> >> Иерархию? Скриптами. Достаточно мелкими.
> >> 23:24:58:netch@iv:~/cvswork/head/sysprog/cvsbackup>wc cvsbackup.pl
> >> 957 4253 27408 cvsbackup.pl
> >> Это реализация очень близкой к иерархическому перемещению идеи.
> AIZ> хех - а еще можно написать новую систему контроля версий
> AIZ> можно вообще все наврнуть на основе rcs только зачем столько жевачки
> AIZ> тратить?
> А зачем эта жвачка была сделана в BK? ;)))
Там это /не жвачка/ 8-)
> >> Мирроры? Тоже можно.
> > >>> Ай, уже в который раз повторяю все заново...
> > AIZ>> вот вот
> > AIZ>> нет что б посмотреть 8-)
> >> Hа что смотреть? Hа обломки истории 2.4? Сам туда смотри, коли больше
> >> ни на что не хочешь. Только розовые очки сними, глаза быстро устают.
> AIZ> мать - откуда ты возьмешь более ранние куски - если их нет вообще в
> AIZ> природе?
> Идешь на ftp.linux.org получаешь полную историю версий не то с 1.0 не то
> с 0.0.1. А ты о чем?
они там не все (во всяком случае были не все) 8-) в частности есть
провалы в версиях 0.99plкаких-то я еще помню как народ пытался найти их
спрашивая в lkml 8-)
--
The cable TV sex channels don't expand our horizons, don't make us better
people, and don't come in clearly enough.
-- Bill Maher
--- ifmail v.2.15dev5
* Origin: EMS JSC (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
