[devel] Метарепозиторий Сизифа

[Alexey Tourbin]

On Fri, Nov 09, 2007 at 01:38:50AM +0300, Dmitry V. Levin wrote:
> > Это тогда философский вопрос получается -- чем мёрж отличается от ребейса.
> > Если и тот и другой одинаково возможны, то в результате у мёрж-коммита
> > и ребейса будут одинаковые деревья, но разная история.
> 
> Лично я воспринимаю rebase как частный и довольно точно определённый вид
> merge.  Я не вижу способа перенести git'овое представление термина
> "merge by recursive" на нашу почву.

Merge -- полное сохранение истории, такой, какой она была, при том, что
в точке мёржа имеется "нематематический катаклизм".  В нашем случае этот
нематематический катаклизм можно сделать немного более математическим
за счёт фактического "перепроигрывания" (или же параллельного
дублирования) истории.  То есть стратегия мёржа в наших руках --
текстуального соответствия не требуется, а требуется выяснять
семантическую возможность мёржа.

Мёрж атомарен только в смысле подключения его к HEAD'у.
Сама по себе транзакция можно состоять из целого дерева коммитов.

Например, я отправил новую сборку perl-XML-LibXML, и сломался
perl-XML-LibXSLT.  Не дождавшись окончания тестовой пересборки,
я собрал libxml2.  Потом я получил результаты по perl-XML-LibXML
и взялся чинить perl-XML-LibXSLT.  Но libxml2 сам по себе уже прошёл
в HEAD.  Движение хеда на рисунке строго вертикальное.

	 /* merged perl-XML-LibXML with fixed perl-XML-LibXSLT
	* | perl-XML-LibXSLT built ok
	* | perl-XML-LibXML built ok against libxml2
	|\| branch is awaken by new perl-XML-LibXSLT 
	| * libxml2 built ok
	* | perl-XML-LibXSLT rebuild failed
	 `* perl-XML-LibXML built ok

То есть здесь транзакция атомарна лишь в том смысле, что потом весь
бранч подцепляется к хеду за один раз.  Но может как бы происходить
новое слияние хеда в саму транзакцию.  В общем, мёрж отражает "более
настоящую" историю, как это на самом деле происходит во времени.

Впрочем, я не против ребейса.
Я просто почему-то всегда думал про мёржи.
Теперь буду думать про ребейсы. :)

> В первом приближении можно, поскольку это не меняет сути дела.
> Я утверждаю, что apt-cache unmet в нынешнем виде не отвечает на тот
> вопрос, на который мы традиционно считали что отвечает.  Это не значит,
> что мы не можем решать глобальную задачу сборки Сизифа, пока не решим
> конкретную проблему apt-cache unmet.

Анметы можно маскировать кофликтами.
Над этим надо будет думать в другом треде.

> > Да.  Это самое слабое место.  После того, как собрались пакеты
> > транзакции, нужно ждать какое-то время, пока не просчитается список
> > на тестовую пересборку.  Это время в среднем наверное превышает сборку
> > поступивших пакетов + последующую тестовую пересборку.
> 
> Это можно обойти, не реализуя свой алгоритм обработки графа зависимостей,
> без использования apt?

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

> > > Наверное, можно сохранять промежуточные состояния жизни транзакции, если
> > > это интересно.  Я пока не вижу, зачем это может понадобиться.
> > 
> > Для анализа промежуточных конфигураций, которые образуются в ходе
> > транзакции.
> 
> Какого рода анализа?

Мне интересно знать, что у кого сломалось и как они это чинили.
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип     : application/pgp-signature
Размер  : 189 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20071109/984c4ef5/attachment-0002.bin>