HEAD/STABLE/branch

[Tomasz Kłoczko]

On Mon, 3 Dec 2001, wrobell wrote:
[..]
> > Załóż to jednak na DEVEL. Do dzisiaj od momentu kmkiedy pisałęm o tych 95%
> > nikt nic ciekawego w tj kwestii nie napisał czyli od tego mometu
> > funkcjonować powinno juz zalecenie takiego a nie innego postepowanai w
> > takich przypadkach, a do połowy grudnia powinien już funkcjonować zestaw
> > builderów gotowych do pzrebudowywanai rzeczy z brancha DEVEL.
> > 
> > Tak czy inaczje jesze raz: na razie głównym celem jest 1.0 w związku z tym 
> > prośiłbym/błagałbym o to żeby możliwie rzadko zabierać sie za coś co by to 
> > opóźniało.
> 
> W grudniu jesli wyjdzie Python 2.2 to go skoncze w branch-u, ktory jest
> juz zalozony dla tej wersji beta Pythona. Zalozmy, ze dla pozostalych
> pakietow (python-*.spec) zaloze DEVEL. Co bedzie za jakis czas
> w podobnej sytuacji? Tez DEVEL? DEVEL-1-1? Ciagle uzywanie DEVEL
> bedzie zasmiecac log-a okrutnie i ciezko bedzie sie w tym polapac.
> Tak mi sie przynajmniej wydaje.
> 
> Hipotetyczna lecz nie niemozliwa sytuacja (nizej opisane softy
> w obecnej wersji maja wiele ciekawych nowych rozwiazan).
> Ja robie obecnie sobie po troszku Pythona 2.2. Zalozmy, ze ktos
> sie zdecyduje robic na bazie snapshotow wersje Postgresql-a 7.2.
> Ja zrobie branch-a DEVEL na postgres-a 7.1.3 ze wzgledu na Pythona,
> a ta druga osoba DEVEL na postgres-a 7.1.3 ze wzgledu nowsza wersje?

Może inaczej. Wytłumaczę rzecz kolejną która dla mnie była oczywista a 
właśnie zorientwałem sie że chyab nie jest oczywista dla innych.

CVS/RCS ma pewne ograniczenia do innych znanych mi systemów kontroli
wersji źródeł jakimi miałem okazje sie posługiwać. Otóż ma możliwość
przypisania do drzewa zmian tylko jednej "etykiety pływającej" czyli z
eng. sticky tag (Przykładowo PVCS nie ma takich ograniczeń). Wprzypadku
cvs domyślnie taka etykieta nazywa się HEAD i pzresuwwa sie ona razem ze
zmianą bez koniecznosci wykonywanai dodatkowo "cvs tag -f HEAD" czy też
kasowania etykiety i zakąłdanai jej w nowym miejscu. Nie ma mozliwości
zakładanai więcej niż jednej etykiety pływajacej ale na dobrą sprawę nie
jest to ograniczenie ponieważ akyrat RCS/CVS branch to nie nazwa punktu
tylko całego odgałezienia zmian. Czyli mówiąc inaczej jest to dość
funkcjonalnie podobne do tego jakby jednak była możliwość zakładania
więcej niż jednej etykiety pływającej.

Jeżeli pobierze się coś a brancha to pobierze się ostania zmiane w czoła
zmian odgałezienia.

W tym wypadku mamy teraz sytuację taką że etykietą STABLE jest taką
etykieta pływajacą dla 1.0 (sam przy tagowaniu pakietyu przesuwam ją). W 
Momencie kiedy zdecydujemy że zamykamy 1.0 dojdzie kolejna etykieta 
zaznacząjąca tą wersję dla całosci. Poprostu całe tagowanei statanie
wykonane popzrez cvs rtag -r STABLE PLD_1_0 SOURCES SPECS.
W tej chwili sporo zasobów które są w Attic ma jednak etykiety STABLE. Na 
dniach i to zniknie/zostanie wyczyszczone. Także pakiety które będą
musiały opóścić ftp (najlepszy pierwszy jak na razie kandydat do czegoś 
takiego to przykładowo mrt) też zostana pozbawione tej etykiety.
Po zamknięciu 1.0 etykietę STABLE bedzie moząń wykorzystać jzu dalej do 
innych celów. Niemniej obecnie STABLE ma być niemal tym czym za kawałek 
będzie PLD_1_0. Czyli nie będzie za bardzo koniecznosci wprowadznia 
dodatkowych etykiet typu DEVEL czy STABLE.

Relizujemy taktykę wersjonowania optymalna dla zasobów o dużej autonomii
(takimi są spece do poszczególnych pakietów) i jest to nieco inna sytuacja
niż typowa taktyka dla wiekszej ilości źródeł w projekcie na jakie
prowoływał się Marcin czy Ziemek. To co w tej chwili także realizujemy do
pewnego stopnia zmusza do tego żeby możliwie szybko zamknąć 1.0 i to też
nie jest przypadkowe. Branchowanie dla DEVEL czy też poruszanie się w
branchu nie jest tak trywialne jak w przypadku pracy na HEAD czyli jeżeli
ktoś zdecyduje sie do zdobienai czegoś dla DEVEL musi to zrobić inaczje
niż w możliwie najprostzym przypadku operowanai na zasobach z systemu
kontroli wersji źródeł i to też nie jest przypadkowe. Na na razie niemniej
mamy jeszcze jednak sporo zmian które mogą wejść do STABLE.

Na razie nie mamy dużego "ciśnienia" na rozwjanie rzeczy do DEVEL. W miarę 
zwiekszania sie tu tegoż ciśnienia jasne że i sam infrastruktura
builderów będzie musiałą być przygotowana do produkcji zasobów z DEVEL.
Ja osobiście ze względu na chęć zamkniecia 1.0 nie beę w tym jednak za 
mocno uczestniczył co oczywsci nie ma oznaczać że jeżli beą 
inni zainteresowani działniem pzredewszytkim w tej swerze to z jakiś 
powodów mieliby się tu czuć blokowani i moga jak najbardziej podejmować 
działnai idące w tym kierunku.

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek w rudy.mif.pg.gda.pl*