On Fri, Jul 06, 2007 at 12:55:32PM +0400, Alexey Tourbin wrote:
> On Fri, Jul 06, 2007 at 11:15:02AM +0400, Dmitry V. Levin wrote:
> > Это зависит.  Если у пакета upstream в git'е, и бранч, из которого ведётся
> > сборка пакета, основан не на релизах а на upstream'ном git'е, то я вижу
> > больше смысла пакетовать в srpm этот самый %name-%version-%release.tar,
> > нежели %name-%version.tar (который имеет все шансы отличаться от
> > релизного по составу файлов) с кумулятивным патчем.
> 
> Простой патч "не держит" как следует переименование файлов.
> У меня есть пакет напр. perl-DBI, в котором я переименовал
> Changes -> lib/DBI/Changes.pod.  Патч будет большим и ценность
> такого патча будет низкой.

Значит, надо добавлять в начало патча шапку a la git diff --stat.

> > Не вижу в этом проблемы.  У меня есть такой забавный пакетик faketime.
> > В нём кода на несколько килобайт, но он использует gnulib на несколько
> > мегабайт.  Я поместил gnulib на другой бранч (у gnulib'а upstream'ный
> > исходный код в git'е), поставил тэг, который время от времени передвигаю.
> 
> И что, ты делаешь фиктивный merge бранча gnulib, который не добавляет
> файлов в основное дерево, только для того, чтобы получить общего предка,
> чтобы создавался тарболл gnulib в .gear-rules?  "Это какой-то позор." :)

Этот merge не совсем фиктивный.  Я мог бы вообще вести разработку
faketime (если было бы куда её вести) на отдельном бранче, а в master'е
только мерджить бранчи.

> > > В общем, кумулятивный патч из gear-tags более-менее подходит только
> > > тогда, когда сборки строго отсчитываются от официальных релизов.
> > 
> > У меня другое мнение.  Если сборки отсчитываются от upstream'а в
> > каком-нибудь виде, в т.ч. снапшотов, то можно сделать кумулятивный патч.
> > Можно даже сделать 2 кумулятивных патча: от последнего релиза до
> > последнего снапшота, и от последнего снапшота HEAD.
> 
> В случае с перлом очень большой апстримный патч будет от последнего
> релиза.
> 
> $ git-describe 5.8
> 5.8.8-702-gb49e4f0
> $ git-diff 5.8.8..5.8 |wc -c
> 12912147
> $
> 
> Такой патч ничего никому не даст, отключить его (и откатиться на 5.8.8)
> всё равно нельзя.

И это правильно.

> > > Я подумал и пришел к выводу, что git не очень-то хорошо подходит для
> > > поддержки нескольких "логически нарезанных" патчей.  Хранить патчи
> > > отдельно в таком случае выходит проще, чем думать, как орагинзовать
> > > бранчи и как их потом вливать друг в друга.
> > > 
> > > Проблема с git'ом вот какая.  Мы сделали измнение относительно версии1.
> > > Потом мы делаем pull версии2.  merge не проходит из-за конфликта с
> > > изменением.  Мы вручную правим конфликт.  Теперь информаци о том, что
> > > представляет из себя изменение относительно версии2, частично потерялась
> > > (оно похоронено в ручном разруливании конфликта).  То есть уже нельзя
> > > логически однозначно восстановить патч для версии2.
> > 
> > Можно сделать rebase, заново разрулить конфликты и получить патчи,
> > сделанные для новой версии, но.  Это другая модель разработки, обычно
> > не очень удобная, поскольку утрачивается история.
> 
> Можно делать вот как: не допускать конфликтных мержев (если они
> задеваются локальными изменениями в коде).  Если мерж оказывается
> конфликтным, то нужно сначала откатить (revert) те изменения, из-за
> которых получается конфликт.  Потом сделать бесконфликтный мерж.
> А потом заново эти патчи накатить, уже разруливая конфликт.
> 
> При таком раскладе получается, что любое локальное изменение всегда можно
> откатить, как если бы можно было отключать патчи в spec-файле.  Впрочем,
> если патчи между собой конфликтуют, то отключать их в spec-файле просто
> так всё равно нельзя.  В этом случае получается то же самое, только git
> лучше.
> 
> В общем, git довольно дубовая система, она не решает тонких проблем,
> а просто не обращает на эти проблемы внимания.  Впрочем, всё равно никто
> не знает, как надо "по-хорошему" решать эти "тонкие проблемы".  Вроде в
> darcs какие-то идеи на этот счет были.

Некоторые полагают, что т.н. исчисление патчей в darcs представляет в
первую очередь академический интерес:
http://article.gmane.org/gmane.comp.version-control.git/50809

> > > В идеале нужна такая система, которая позволяет "логически
> > > восстанавливать" патч для каждой версии, а не хоронить конфликты
> > > под мёржами.
> > > 
> > > ПОСЛЕ КОНФЛИКТНОГО МЁРЖА ПАТЧ УЖЕ НЕЛЬЗЯ ОТКАТИТЬ РЕВЁРТОМ,
> > > правильно я понимаю?
> > 
> > Можно, при этом, скорее всего, придётся разрулить новый конфликт.
> 
> Ну вот получается, что в ряде случаев патчи в src.rpm пакете отключать
> проще, чем откатывать "старые" локальные изменения в git'е.

В ряде случаев при попытке отключить в srpm'е один патч перестаёт
накладываться другой патч.
Нет здесь простого решения.


-- 
ldv