A ssie, i to bardzo, szczególnie w naszym wykonaniu. Mianowicie, już po raz kolejny natknąłem się na ten sam problem: załóżmy że utworzyłem sobie nowego brancha (dla ustalenia uwagi niech nazywa sie on DEVEL) i na nim wprowadzam pewne zmiany. Trwa to jakiś czas więc w tym czasie ktoś inny zdążył zrobić jakąś kosmetyczną poprawkę tego speca na HEAD. W takiej sytuacji próba zmerge'owania brancha DEVEL na HEAD zawsze kończy się koniecznością ręcznego rozwiązywania konfliktów. Nawet w przypadku gdy zmiana na HEAD jest naprawdę kosmetyczna, i jako taka, bez problemu zintegrowałaby się ze zmianami na HEAD -- zawsze pozostaje kwestia nieszczęsnego changeloga generowanego z $Log$.
Satysfakconujące mnie rozwiazanie jest takie, że w repozytorium sekcje %changelog speców pozostaja puste, a ich generowanie dokonuje się na builderach tuż przed zbudowaniem pakietu źródłowego. W tym celu trzeba do skryptu builder dodać opcję (np. -c lub inną jeżeli taka już istnieje), która po ściągnięciu speca z repozytorium wklei sekcję %changelog wygenerowaną na podstawie cvs log nazwa.spec.
Plusy takiego rozwiazania. Po pierwsze, możliwość generowania changeloga takim jakim powinien być czyli z osobnymi wpisami dla każdej zmiany, a nie w dotychczasowej formie gdzie używamy wrappera który tworzy jeden wpis zawierający listę wszystkich zmian. Po drugie, możliwość kontrolowania ile wpisów trafia do pakietu, dzieki czemu odpada konieczność czyszczenia co jakiś czas changeloga w repozytorium. I po trzecie, i chyba najważniejsze, zmniejsza to redundancję w repozytorium.
Opisana wyżej metoda staje się jeszcze bardziej atrakcyjna, gdy repozytorium jest w SVN, a nie CVS. W tym pierwszym istnieje możliwość poprawienia commitloga określonej rewizji.
