Kirill Maslinsky пишет:
> On Wed, Mar 12, 2008 at 07:11:05PM +0300, Aleksey Avdeev wrote:
> 
> [...]
> 
>>   При таких запросах (несколько апстримов, rpm пакеты для нескольких
>> дистрибутивов) логичной будет следующая организация:
>>
>> 1. Каждому файлу (запакованному в src.rpm) -- свой бранч. Обоснование:
>> данные файлы могут жить своей жизнью, путешествуя между апстримами, и
>> хранение их отдельно способно достаточно сильно упростить мерж.
> 
> Не понял, что имеется в виду под файлом в данном случае? 
> Поясни на примере, если можно. 

  OK, возьмём для примера php-mcrypt (см.
<http://git.altlinux.org/people/solo/packages/?p=php-mcrypt.git;a=summary>).
  Данный подход там начал применяться недавно (только в последней
сборке) и не в полном объёме... Но для примера будет достаточно, думаю
(в apache2.git данный подход применён более последовательно, но он
слишком тяжёл для примера).

  Структура бранчей php-mcrypt.git:

ALT/php-mcrypt/srpms -- бранч из которого собирается rpm.
|     В него мержится всё остальное. Он же -- master.
|\
| ALT/php-mcrypt/spec -- бранч содержащий только spec.
|
 \
  ALT/php-mcrypt/gear_rules -- бранч содержащий .gear-rules или
      .gear/rules. Если rules написан с привязкой к тегам -- необходимые
      бранчи мержатся сюда (с -s ours).

  В дальнейшем в данном репозитарии могут появиться бранчи
ALT/php-mcrypt/php-mcrypt{.ini,-params.sh} (если соответствующие файлы
будут изменены).

  Данную схему можно формализовать так:

1. Репозитарий построен так, что каждому %source и/или %patch в спеке
соответствует:

  а) каталог либо файл в корне репозитария;

  б) правило в rules, для генерации данной сущности на основе тегов
репозитария.

2. spec, rules (.gear-rules или .gear/rules -- по вкусу) и
файлы/каталоги из п. 1.а живут в отдельных бранчах, смерженных в
"главный" (тот, из которого и осуществляется сборка).

3. Бранчи содержащие теги требуемые для rules мержатся в бранч данный
файл содержащий (с -s ours), если они ещё не смержаны в "главный". (Цель
данной опирации -- обеспечение наличия данных тегов среди прдков
комиитов сборочного бранча, для корректной работы gear-update-tag.)

4. Результат работы gear-update-tag коммитится в сборочный бранч.

  В качестве более полного примера -- смотреть лучше на apache2.git: там
использованы все описанные механизмы (артефакты там есть, но их не много).

>  
>> 2. Создать полиси на именование бранчей и тегов, чтобы имена указывали
>> на апстрим, связанный с данной сущьностью) явным образом. Например
>> <апстрим>/<имя пакета>/<имя бранча или тега> (более детальные примеры --
>> в моих репозитариях).
> 
> Пока более первоочередная задача для введения полиси -- это количество 
> и предназначение texmf-деревьев а также размещение файлов по ним. 
> А бранчи... бранчи вырастут сами! ;)

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

-- 

С уважением. Алексей.