>>Массовое помешательство - не повод присоединяться.
>
>Безусловно. Только не вижу помешательства в том, что сказал (вообще это
>было бы странно).Я же говорю - массовое. По отдельности все люди - умные. Психологию толпы внимательно не изучали? Я тоже:), но кое-что усвоил.
>>>Наверное, надо попробовать, чтобы понять.
>>Марихуану, говорят, тоже надо попробовать, чтобы понять. Не аргумент.
>
>Да, я тоже нечто подобное подумал, когда писал :)))) Вы правы,
>привыкание вызывает.
Как Windows GUI, да? ;) *остальная часть абзац вырезана цензурой, т.к. воспоминания автора о настройке DNS-сервера через множество окошечек и закладок вылились в неприемлемый для публикации вид*
Шучу, шучу.
>[оверквотинг удален]
>>А получилось именно опускание. Я всё понимаю, нервы, обиды, то, сё
>
>Та ни :)
>
>>но резкость Ваша, если честно, несколько непривычна, особенно в отношении проекта,
>>отнюдь не борющегося с вами.
>
>Скорее сообщества, а не проекта. Повторюсь, те же сектанты со мной
>отнюдь не борются, но резкости к ним куда больше -- потому
>как вред вокруг больше пользы.
Вы с сектами, видимо, плохо знакомы... Там настройка даётся обычно уже на втором-третьем занятии: "мы - правильные, а остальных надо переделывать". Весь вопрос в том, как это "переделывать" реализуется, если очень мягко - то они с вами "не борются", да. Но разница, тем не менее, огромна: секта старается изменить людей; ради "всеобщего блага" или для обогащения "учителей" — не суть.
FreeBSD-сообщество (и не только оно, конечно) - не пытается изменять людей. Членов FreeBSD-сообщества никто не приманивает ("смотри, как у нас хорошо!"), не держит (явно или неявно: например, в некоторых сектах практикуется "парность", если ты уходишь из секты, то твоя "пара" тоже выгоняется), и т.д.; у них имеется полная свобода воли делать что угодно - при условии, что это не вредит FreeBSD (которая не самоцель, но лишь реализация неких идей, и, соответственно, изменения, касающиеся FreeBSD рассматриваются именно в контексте этих идей). Если вам не нравятся чужие идеи - ваше право. Вы можете форкнуть FreeBSD, можете развивать что-то ещё - или не развивать вообще, а копать в саду цветочки, FreeBSD-сообщество мешать вам не будет. Если же вы разделяете положенные в основу FreeBSD идеи - добро пожаловать. Не могу понять, эта позиция Вам кажется "промыванием мозгов"?
Ну а фанатиков, которые кричат "XXX — это круто!" хватает везде. Им самим нужно ощущение, что они знают Истину, и они промывают мозги сами себе, просто чтобы заполнить пустоту в голове.
>>>А из, скажем, git и bzr очень хорошо и на собственной практике вижу,
>>>чем первый лучше.
>>Что ж вы так, ведь надо же попробовать, чтобы понять, а?
>
>Ась?
>
>http://lists.altlinux.org/pipermail/smoke-room/2008-March/03...
>http://lists.altlinux.org/pipermail/smoke-room/2008-March/03...
Прочитал. Понял, что хоть RCS — та ещё помойка, но остальные немногим лучше.
>>>Тут уже мыцыцыклы привезли, а вы всерьёз обсуждаете переход с трёхколёсного велика
>>>на двухколёсный, ковыряясь в носу и объявляя мыцыцыклистов сосунками, потому как
>>>у них педали не крутются, а у вас крутются и потому
>>>ездить можно.
>>Вот сколько гляжу, велосипеды встречаются в жизни до сих пор чаще мотоциклов.
>>С чего бы?..
>
>В жизни процесс копирования сложней ;)
Вот именно. Git может быть хоть двести раз круче SVN, но если в _данном_контексте_ SVN вызовет меньше проблем, то не вижу криминала в выборе именно SVN.
Кстати, в том же OpenBSD потихоньку допиливают OpenCVS, и переезжать не собираются вообще. Хотя тоже ведь не дураки. Может, им тоже какая-нибудь таинственная фирма запрещает переезжать с CVS? То есть это не разработчики такие неумехи или дураки, это в некоей фирме сидят не слишком умные личности, которым очень нужно поиметь альтернативную реализацию CVS, так? Интересно, правда, как при этом данная фирма, несмотря на то что управляется не слишком умными личностями, умудряется содержать немаленький в ообщем-то проект, ну да это же детали, правда?..
>>А сосунками объявляете как раз вы велосипедистов.
>
>Да нет же. Не "велосипедистов", а "тех, кто привык крутить педали
>и не понимает, как это -- без них". Сам-то как
>раз с младых ногтей на чём попало езжу и нормальных вменяемых
>интересных людей -- с логикой на борту -- знаю достаточно :)
Ну и с чего вы решили, что "не понимает"? По-вашему, как "поймёт", так сразу забросит свой велосипед? Знаете, вот это как раз типичная логика людей с промытыми мозгами.
>Пример предложен в поведении, а не в этикетке.
Очень хорошо. Что ж, мы с Вами видим ситуацию с разных (примерно на пол-пи повёрнутых друг относительно друга) позиций. И, видимо, это не преодолеть. Засим предлагаю плавно успокоиться и каждому продолжить своё дело... Время рассудит.
>[оверквотинг удален]
>Знаете, когда удобно? Подумал об одном -- завёл бранч. Пришла
>(или вспомнилась) посреди лопаченья кода ещё одна идея -- сделал другой
>бранч (отсюда же, от основного или любого другого), в нём реализовал,
>закоммитил и вернулся лопатить дальше. Завершил логический кусок работы --
>можно спокойно и с минимальной затратой времени и сил помержить.
>
>Даже для одного проекта на одном хосте помогает -- поскольку машина при
>этом не заставляет подстраиваться под себя (что в какой коммит надо
>сделать и в каком порядке), а готова помочь изложить и код,
>и _о_ коде.
Звучит красиво, не спорю. Впрочем, про мосты Git-SVN я уже всё сказал.
У меня всё проще: если что, я просто копирую нужную папку, вношу изменения в неё. Наглядность лучше (вот оно, не надо команды вводить никакие). Алгоритмы мержда относятся уже к деталям реализации и вполне портируемы между разными VCS (при условии, что они достаточно корректно написаны с точки зрения разделения функциональности между модулями, но это уже совсем другой разговор, опять же, относящийся к конкретным программным реализациям). И чем будет
cp -R dir1 dir1.branch
[здесь работаем в любом порядке с бранчами; по необходимости делаем (cd dir1.branch && cvs update)]
(cd dir1.branch && cvs update && [ресолвинг конфликтов, от схемы работы VCS не зависит] && cvs commit -m "Test branch merge")
отличаться от того, что предлагает git (создать бранч, переключаться между ними по ходу дела _внутри_одного_каталога_, а потом сделать merge), кроме занимаемого места - не совсем понятно. Да и это занимаемое место, как я уже сказал, наглядности прибавляет - вот они, обе ветки под руками, делай с ними, что хочешь.
А уж поделиться с результатами работы в приведённом мной примере и подавно легче: уж чего-чего, а способов для расшаривания папок на любой вкус (с локами и без, онлайн и оффлайн...) придумано в наше время столько, что заблудиться можно. А Git и иже с ним в данном контексте, получается, как раз велосипед изобретают. ;)
>[оверквотинг удален]
>Вот. А у меня главное -- это не "процесс продумывать", а
>дело делать. Чем меньше времени займёт "продумывание процесса" (rigid upfront
>planning, если хотите почитать, скажем, Johanna Rothman) -- тем меньше времени
>окажется убитым заранее при обязательно вылазящих непредвиденных обстоятельствах.
>
>>А если не продумывать - никакая VCS не спасёт, только разве что смерть
>>оттянет.
>
>Ничего, что некоторые VCS помогают и историю рефакторить при необходимости, пока она
>не опубликована?
Вообще, нехорошо это - историю править. Но если речь вести о мердже "приватных" бранчей в "общую" ветку, то там, как правило, есть чёткое требование: коммиты должны быть разделёнными функционально. Если этого правила нет, то "внутренняя" история - лишь костыль, который оттянет момент, когда код станет настолько сложным, что в нём полностью не сможет больше разбираться _никто_. Правка "внутренней" истории может помочь, но это по сути то же ручное разбиение diff'ов, от которых, якобы, Git помогает избавиться. То есть мы усложняем систему (или, по крайней мере, создаём сложности в виде этапа перехода), но имеем те же проблемы. Ну и нафига, спрашивается?
>Кстати, вот и аналогия -- cvs суть waterfall development, а git --
>agile. Про влияние на риски разработки можете вон http://pragprog.com/titles/jrpm заказать
>и почитать (опять же при желании и интересе к управлению проектами
>разработки софта).
Сказки и я сочинять умею. Вы так говорите, как будто waterfall — как бы это сказать помягче? — бесперспективняк. Такие вещи я как раз и называю массовым помешательством. Ответная ссылочка (заказывать ничего не надо, но многабукаф): http://www.rsdn.ru/forum/message/2677686.all.aspx . Можете считать её иллюстрацией или аргументом, суть не изменится. :)
>>К слову, тот функционал легко реализуется шелл-скриптом. Для любой SCM.
>>Сами догадаетесь, как? Если хотите сказать, что, мол, вот в git это уже
>>есть, а в остальных надо допиливать - вспомните словосочетание Unix way.
>
>Если можно реализовать для одной SCM -- значит, на других можно сэмулировать.
> Только не получится ли очередное распихивание XML в RDBMS? (в
>смысле закручивание гвоздя отвёрткой)
Закручивание гвоздя отвёрткой характеризуется усложнением процесса работы, по сравнению с имевшим место ранее (закручивание шурупов отвёрткой). ИМХО, нет смысла делать полный рефакторинг в подобном случае. Потому что результат рефакторинга будет уже _другой_ VCS. А так - мы имеем отлаженную VCS, с дополнительной "обёрткой". Если и обёртка, и VCS сделаны качественно (а это не сложно при малых размерах "обёртки" для средней руки программиста), и "обёртка" использует только открытые интерфейсы VCS, то проблемам технического плана будет взяться практически неоткуда (нехватку inode на жёсктом диске разработчика мы ведь не учитываем, так? :) ).
>>>> Полезно (для тех, кто не следит за тем, что делает)? - пожалуй.
>>>Вы за регистрами следите, когда пишете на шелле? Нет? Ай-яй-яй.
>>Слежу.
>
>Можно поинтересоваться, как именно? :)
Ммм... Имелся в виду регистр букв или регистры процессора? :) За вторым не слежу - при написании шелл-скриптов я полагаю шелл "непогрешимым". Если я не могу полагать шелл "непогрешимым", то либо проблема в шелле (выбираю другой шелл или пишу свой), либо во мне (выбрал не тот инструмент для работы). Оба эти случая не имеют отношения к собственно написанию шелл-скрипта и, соответственно, к "нормальному" использованию шелла. Возвращаясь к нашим баранам, получается, что _проектирование_ находится _за_рамками_ конкретной VCS. VCS - это инструмент. Если используются методы, при которых данная конкретная VCS (CVS, SVN, Git, VSS...) не мешает работать - то зачем использовать другую? "Чтобы было"? Такой подход полезен (и то в разумных пределах!) при отсутствии конкретных требований к инструменту, например, в случае разработки не под конкретного заказчика, а чисто венчурной.
Написание же скриптов с постоянной оглядкой на те или иные "нестандартные нюансы" работы шелла значит лишь перемещать проблему с этапа разработки на этап поддержки. Если мне будут платить именно за такую работу — я сделаю, если не посчитаю приемлемым отказаться. Но предварительно откажусь ото всякой ответственности за последствия. Я косяков и без того наделаю:). А так получается как в известной фразе: "Понимаем, что делаем глупость, не дураки!"
>>Я охотно верю, что он разбирается лучше меня. Но судя по статье
>>и правкам в ней, он разбирался по крайней мере на момент
>>её написания хуже, чем нужно для того, чтобы считать статью
>>достойным аргументом в пользу git.
>
>У меня это не аргумент, а иллюстрация :) Плюс повторюсь --
>"хуже...нужно" штука относительная, для адекватной оценки надо иметь сопоставимый уровень (да-да-да,
>я понимаю, что именно сказал, можно не тыкать носом :)
Иллюстрации хороши в докладе... А здесь они смотрятся не лучше, чем графики производительности браузеров (как я ни надеялся, дожил и до такого маразма) в речах фанатиков того или иного продукта.
>[оверквотинг удален]
>Так вот Вы можете взять нож, который почти ничем не лучше, и
>утешать себя, что ещё на два-три года его точно хватит (при
>этом отмечая, что предыдущий давно бы показал свою неадекватность, но инструмент
>марки "пергвоздь" выручал во многих крайних случаях).
>
>Но это не изменит того, что сталь там будет примерно та же,
>и заточка примерно та же. В общем, откладывание проблемы, а
>не идентификация и решение.
>
>(воспринимать этот фрагмент опять же может быть удобней в свете письма Питеру)
Ваша уверенность в том, что изначальным ножом пытаются открывать консервы, не может не поражать. Вы искали глупость - вы её нашли. Для вас она есть, может быть, даже осязаема. Но если так - разговор получается бесполезен. Когда используется обычный нож для открытия консервов — это и есть то же, что запихивание XML в СУБД. Это использование плохо совместимых инструмента и задачи.
Но речь-то о другом. Я _умею_ пользоваться имеющимся у меня ножом. Выработаны определённые рефлексы. Я знаю, как надо положить тот или иной предмет и как держать для этого нож, чтобы лучше сей предмет разрезать. При этом консервы я не открываю этим ножом. Я с ними просто не сталкиваюсь, либо они являются свидетельством того, что что-то надо менять в отделе закупок, например, моё кафе работает только со свежими продуктами:). Это если и не даёт само по себе определённые гарантии пользователям, то, по крайней мере, защищает их от проблем на одном из фронтов (аллергия на определённые консерванты, например), которые в итоге и моими проблемами станут (у меня сократится количество постоянных клиентов). Минимизация рисков, так сказать.;)
>>И если вас peter@ пошлёт в лес - лично я буду не на вашей стороне.
>
>У меня нет "стороны".
Есть. Она всегда есть. Внутри неопределённого временного диапазона она может меняться, сейчас вам более симпатично одно, через (мгновение, минуту, день, год) - другое. Но в каждый момент времени эта "сторона" (ваша позиция по тому или иному вопросу) фиксирована. В частности, она фиксируется в момент отсылки коммента. :)
Не может быть "стороны" только в отношении тех вопросов, о существовании которых вы не знаете. Будем копать дальше в область психологии индивидуума? :)
А насчёт peter@ и p4 - Вы, повторюсь, текст, ссылку на который дали, сами читали внимательно? Там человеческим языком написано, что части разработчиков p4 оказался _неудобнее_ (то есть, производительность и/или качество их труда снизились). Поэтому было выбрано решение, которое позволит разработчикам использовать удобный для них инструментарий (хоть CVS, хоть Git), и при этом даст все премущества в виде сохранения метаданных и т.п. ИМХО, _такое_ решение выглядит гораздо более разумным, нежели "а не слабо ли нам всем перейти на Git?"
Может быть, Вы считаете, что это разработчики неправильные, и они делают неправильный мё… код? Но они его делают. И делают хорошо, иначе бы их код никого не интересовал. Переход на git снижает качество этого кода — что, кому-то от этого лучше станет?
По Вашей логике, UMTS тоже ненужная технология, ведь есть Wi-Max…
