On Fri, Nov 09, 2007 at 02:28:31AM +0300, Alexey Tourbin wrote:
> On Fri, Nov 09, 2007 at 01:48:45AM +0300, Dmitry V. Levin wrote:
> > Лог сборки - это свойство исходного пакета в данном репозитории для данной
> > архитектуры.  Например, это можно представить в виде
> > исходный_пакет/архитектура.
> 
> Точкой входа (top-level каталог) является имя src.rpm пакета.
> типа
> 	.git/
> 	glibc/
> 	bash/
> под каждым каталогом буедт что-то типа
> 	bash/
> 		SVR
> 		i586
> 		x86_64
> это уже файлы; SVR -- это "чистая информация".  i586 и x86_64 --
> это логи сборки.  Тут такая особенность, что мы не имеем права помещать
> в репозитарий логи сборки от разных SVR, если речь идёт о синхронизации
> основных архитектур.  И есть ещё эти неосновные архитетуры, которые не
> нужно синхронизировать.  Если их как-то хранить, то опять усложняется
> структура дерева фс.

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

> Теперь к вопросу, как отличить фактический лог от тестового.
> Косвенным признаком может стать изменение файла SVR.  Когда
> файл SVR изменился, то в этом месте логи фактические,
> а во всех случаях они тестовые.  Но этот признак плохо
> соседствует с "неосновными архитектурами".

Ещё раз предлагаю ставить тэги на логи "настоящих" сборок.

> На это наслаивается ещё одна проблема.  Желательно уметь формально
> отличать "успешные" логи сборки (зелёные) от "неуспешных" (красных).
> Как сохранить информацию красный/зелёный (без заглядывания в лог)?
> Фактические логи по определению всегда успешные (при синхронизации
> архитектур), а статус тестовых логов i586 и x86_64 при очередной
> тестовой пересборке может между собой отличаться.

Т.е. ты хочешь вместе с логами хранить некоторые их атрибуты, которые
можно будет увидеть, не заглядывая в логи?
Попробуй поместить эти атрибуты в файлы по соседству.


-- 
ldv