CVS znowu.

[Grzegorz Stanislawski]

On Wed, 20 Jan 1999, Tomasz Kłoczko wrote:
> On Wed, 20 Jan 1999, Grzegorz Stanislawski wrote:
> > On Wed, 20 Jan 1999, Tomasz Kłoczko wrote:
> > > Tak jak to widzę. Jeżeli masz alternatywny pomysł ..
> >  Troche mi to sobie trudno wyobrazic. Zalozmy ze ktos zechce wprowadzic
> > jakies zmiany do zrodel. Wyglada na to ze musi po tych zmianach
> > wyprodukowac diffa i wyslac go na cvs. Moze to zrobic na dwa sposoby albo
> > [..]
> >  W obu przypadkach (tak mi sie przynajmniej wydaje) nie mamy zielonego
> > pojecia kto jest odpowiedzialny za konkretna linijke w zrodlach. Trzeba
> > [..]
> >  Pozostali ludzie, beda musieli po zrobieniu update'a spatchowac swoje
> > katalogi i o ile przy drugim rozwiazaniu da sie to jakos przezyc, to
> > pierwsze z nich jakos czarno widze.
> 
> Załómy, że mamy pakiet XX i w kolejnych trzech wersjach mia on trzy wersje
> speców w CVS oznaczoe rewizjami (kolejno) 1.1, 1.2, 1.3. Tu trzeba
> zaznaczyć, ze rewizje te to tylko oznaczenia wewnętrzne w CVS i nie mają
> one nic wspólnego z wersjami pakiety XX. Załóżmy, e te kolejne trzy werje
> pakietu to 0.1, 0.2 i powiedzmy 1.0. Jednoczęśnie w trakcie preparowania
> kolejnych wersjio speców okazało się, że werje 0.1 i 0.2 miały jakiś tmp
> race, którego w 1.0 nie było ale w 1.0 pojawia się konieczniość
> patchowania makefile. Jak po tym wszystkim będą wygladać drzewka źródeł w
> SOURCES i SPECS:
> 
> Kolejna sprawa, to to, że etykiety <%name>-<%version>-<%revision> są
> nakładane dopiero wtedey kiedy zapadnie decyzja o tym żeby pakiet
>
 Wszysko fajnie tylko nie powiedziales skad sie beda braly te rewizje
ktore, beda w tym braly udzial. Czy kazesz ludziom pisac z palca diff'y?
Czy bedzie tak ja pisalem poprzednio ze po kazdej zmianie beda produkowac
diff'a i podsylac go? W tym przypadku po pierwsze niewykopiemy cie
spod zawalu diff'ow, apo drugie nie bardzo moge sobie wyobrazic
numerowanie rewizji, bo cvs za kazdm razem bedzie dostawal nowy plik. A
miedzy ludzmi wysylajacymi diff'y moze wystapc "race condition"
 Przy takim rozwiazaniu zaczynam sie zastanawiac po co ten caly cvs.
 
 Powolujesz sie co chwile na cvs z GNOME'a, przygladnij sie jak tam to
jest i na kazdym innym cvs'ie. Wszyscy trzymaja zrodla a nie diff'y.

> > > Powolywales sie na rpm'owe drzewko do robienia pakietow. Jest w nim
> > katalog BUILD w ktorym sa zrodla programow. Moim zdaniem takie cos powinno
> > sie znalezc w cvs'ie. Wstawi sie tam pakiet np takie rc-scripts i
> > bedziemy go sobie obrabiac. W pewnym momencie oglosi sie "code freeze"
> 
> Moment BUILD to jest katalog roboczy w którym wszystko jest rozpakowywane
> i budowane, a po wszystkim to co tam było utworzone powinno być
> wykasowane. Patche i reszta archiwów źródłowych, ikonki pakietów są
> przechowywane w SOURCE i dlatego też w ten katalog w CVS wpadają patche.
> 
Tak jest, jak wszystko bedzie gotowe, moze a nawet powinien byc
wykasowany. Ale modyfikacje programu robi sie wlasnie tam.
Nie wiem jak ty ale u mnie normalnym sposobem obrabiania pakietow jest:
 rpm -bp pakiet.spec 
 cd ../BUILD
 cp pakiet paket.new 
 cd pakiet.new 
 a potem jakies zmiany, make i costam innego
 cd .. 
 diff -ruN pakiet pakiet..new >../SOURCES/pakietN.path
 teraz tylko modyfikacja speca i gotowe.

 Dzieki CVS cala ta zabawa moze byc skrocona do 5 operacji
 cvs checkout; (zmiany, make i costam); cvs commit
 cvs diff i uzupelnienie speca. 
 Ostatnie dwie beda robione zadziej niz obecnie, po ogloszeniu "code
freeze"

> 
> kloczek

Grzegorz Stanislawski
Open-Net / PKFL