On Fri, Feb 02, 2007 at 12:21:37PM +0300, Mikhail Yakshin wrote: >>>> Ещё пока не выработалась схема по правильной работе с патчами в git. >>>> Вообще-то они должны быть в отдельных бранчах. Хранить патчи в виде патчей >>>> при использовании git это очень нехорошо. > MY>> Значит, нам нужен как минимум обратный инструмент - который после > MY>> srpmimport конвертит "Patch: ..." + "%patch-что-то-там", заводя их в git. >> См. первую строчку моей цитаты. Выработается -- можно будет писать. MY> Ну, оно само по себе не выработается, если не будет некоего инструмента, MY> который бы фиксировал эту практику. То же самое, как сейчас бардак по MY> большому счету с выпускающими тэгами из-за отсутствия gear-release. Ты её сначала придумай и документируй. Мне -- слабо. Смотреть при этом рекомендую на новую систему сборки ядер, это _единственный_ образец в сизифе более-менее удобной работы со множеством патчей в отдельных бранчах. >>>> Думаю скорее группа пакетов для разных workflow. Например gear-svnupdate >>>> не должен лежать там же где все остальное. Потому что он хочет svn, >>>> который не всем нужен. > MY>> Нам хотя бы один базовый пока набросать %) >> Базовый не требует ни одной утилиты из отсутствующих в пакете gear, все >> остальное -- вариации на тему :) MY> Такой "базовый" не требует ничего, кроме бинарного редактора - все файлы MY> можно отредактировать вручную, и TCP-пакеты тоже разослать %) Ты преувеличиваешь. Для базовой сборки пакетов достаточно gear, rpm-build и hasher. Это -- базовые утитилы. Остальное обертки. Ещё есть etersoft-build-utils, которая обертка, но как раз оборачивает наиболее частые действия. В общем-то сейчас я совершаю ой как мало действий которые не автоматизируются этим набором. Когда вся сборка будет через git, таких действий будет ровно 0. Так что речь идет о высокоуровневых утилитках, или утилитках для специфических _разных_ workflow для разных _особых_ задач. Как например тот же svn-импорт. >> Разумно. Только с find'ом боюсь весело будет. Потому как в подкаталоги >> репозиториев смотреть не надо. MY> Ну, если будет тормозить - ограничим по -depth что-нибудь. Чтобы не MY> хватал лишнего - будем следить, чтобы в каталоге репозитария был .git. [mithraen@mw git]$ time find | wc -l 0.33user 1.06system 0:57.24elapsed 2%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+349minor)pagefaults 0swaps 187150 :) Это при том что оно почти все в кэше, и там RAID 0+1. На перловке я знаю как написать чтобы это работало (не обходить лишние каталоги), а вот как на шелле -- увы не знаю. > MY>> 2. Именовать, надеясь на комплишен. Имена тогда значительно длиннее и > MY>> максимально описательны. Возникает проблема completion space. Фактически > MY>> обязательно использование completion. Как правило, вводится некий > MY>> префикс наименования семейства утилит (git-*, gear-*, hsh-*, Sisyphus-*). >> А вот фиг там. git-* вообще-то deprecated, надо пользоваться git *, к >> примеру. Вот как раз для удобного разделения completion namespace. MY> Ссылку на то, что он deprecated, кстати, можно? Там предлагается MY> какая-то аргументация? Это в этом листе озвучивал ldv@ > MY>> В качестве чуть альтернативной реализации - это когда делается одна > MY>> "объединяющая" утилита (как в cvs, svn, git, gem) у которой первый > MY>> параметр - команда, которую надо выполнить. Удобно, если есть умный > MY>> комплишен а ля zsh или bash-completions, довольно неудобно, если нет. >> Ага. MY> Что-то мне подсказывает, что zsh сейчас у нас не default shell, да и MY> даже bash-completions стоят хорошо если у трети народа. Это отдельная тема все-таки. > MY>> Плюсы - наглядно, не надо запоминать практически ничего, кроме первых > MY>> букв префикса. > MY>> Минусы - чуть медленнее набирать, большая надежда на completion, надо > MY>> продумывать так, чтобы удобно было комплитить и в completion попадали > MY>> только нужные команды. > MY>> Есть поклонники как одного стиля, так и другого. Поэтому, чтобы не > MY>> мешать друг другу и не ломать копий - все равно это абсолютно вопрос > MY>> привычки/удобства для конкретного человека - предлагаю сделать и так, и > MY>> так - ровно как с опциями (-f и --force). Сделать симлинками или > MY>> алиасами 2 варианта вызова - и длинный, и короткий. >> Понимаешь... в любом случае upper case utilites это зло. MY> Давай все-таки не смешивать. Есть 3 отдельные темы: MY> 1) Стиль наименования утилит - нужен и "короткий", и "длинный". MY> Согласен? У кого-то еще какие-то мнения есть? MY> 2) Upper case для именования утилит. Твое мнение я понял, свое - MY> озвучил, есть еще у кого-то какие-то мнения? >> Тем более что всем этим утилитам место в основном в gear-.* namespace. MY> 3) Предложение убрать разделение на утилиты "низкого уровня" вроде MY> gear-*, hsh-* и т.п. и "высокого уровня" - те, что лежат в MY> etersoft-build-utils / comfort? Я тогда его совсем не понимаю... gear-* это не низкий уровень. Вообще-то это обертка над git и некоторыми другими утилитами. Точно так же как etersoft-build-utils. -- С уважением, Денис http://freesource.info ---------------------------------------------------------------------------- Т.к. Compact уже выпущен, то все что не успели исправить - ошибками не считается. -- rider in #3005