okolo cwierci tysiaca zmian w cvs w ciagu 48h

Tomasz Kłoczko kloczek w rudy.mif.pg.gda.pl
Czw, 29 Lis 2001, 17:08:44 CET


On Thu, 29 Nov 2001, Tomasz Trojanowski wrote:

> On Thu, 29 Nov 2001, Michal Margula wrote:
> 
> > > > Czy mrożenie jest równoważne z zakazem jakichkolwiek prac na HEAD?
> > > 
> > > Tak, na HEAD tylko poprawki sluzace mrozeniu. Nowe rzeczy,
> > > nie sluzace mrozeniu - do brancha marsz!
> > 
> > Nie bardzo rozumiem sens tego. Powinien być osobny branch dla STABLE, a
> > nie dla eksperymentów. Czyli co - do momentu wyjścia następnego mrożenia
> > PLD będziemy musieli w ogóle nie ruszać HEAD, bo a nóż będą jakies błędy
> > (a wtedy te błędy musimy poprawić dla wersji z poprzedniego mrożenia).
> 
> Mi też to koliduje z wyobrażeniem jakie miałem jeżeli chodzi o pracę
> w CVSie. Wydawało mi się, że główna linia jest na HEAD, a jeżeli ma
> dojść do wypuszczenia jakiejś wersji, czy też w naszym przypadku mrożenia,
> robi się to tworząc BRANCHa. Ale cóż, człowiek uczy się całe życie ;)

To wcale nie blokuje tego żeby mrożenie robić nie a branchu. Systemy 
kontroli wersji są generalnie tylko pewna platforma. Do tego tzreba 
dołozyć zespół pewnych dodatkowych regół posługiwania się zasobami 
przechowywanymi w systemie kontroli werji.
Owszem jest tu kilka standardów ale zadwn tak naprawdę nie jest lepszy lub 
fgorszy od drugiego. Jedne niemniej nadaja się do grup z ograniczonymi 
zasobami ludzkimi a ine mniej. Pzrykładowo model jaki próbuję forsować 
wiadomo nie od dzisiaj że włąsnie nadaje się dobrze do systuacji kiedy są 
ograniczenai zasobów "mocy" ludzi nad tym wszystkim parcujacymi. Po cześci 
wymusza/sugeruje skupianie się na jednej linni zmian która możliwie szybko 
powinna być zamknięta. Imnny model stosowany np. w Debianie z wydawaniem 
RC nadaje się wtedy kiedy jest nadmair osób pracujacych nad człością i 
priorytetowe jest zniechecenie do dokonywanai jakichkolewiek zmian. W 
Boingu parędziesiat lat temu kiedy tam właśnie wymyślano systemy kontroli 
wersji źródeł/dokumentów po jakimś czasie stwirdzono że sieganei do 
brancza dla osób pracujacycm zniechecało do dokonywania zmian. Ergo 
wrzucnie czegoś na brancha wskazane jest w sytuacji keidy zasoby są juz 
niemal wykończone .. a tak u nas jeszcze nie jest (taki stan IMHO uzyskamy 
w momencie kiedy wszystkie pakiety które beziemy chcieli mieć będą się 
budować w kupie).

> Nie przekonuje mnie zupełnie argument, że pewne zmiany w repo trzeba by
> dublować.

Zerknij na zmiany Jakuba i ankrego z ostanich parunastyu dni. Gwnie 
tłumacznia dodawanie manów w różnych jezykac i inna kosmetyka. W moim 
przypadku też sporo bło tego typu zmian. Są to zmiany które niezaleznie od 
tego czy benda w branchu czy na HEAD i tak tam się znleźć pwinny. Czyli 
ewjezlei w tej sytuacji powedzmy tydzeiń temu wprowadzilibysmy brancha to 
zmusiłbyś tu kilak osób żeby te paręset zmian co do sztuki zdublowali na 
HEAD i na branchu.

> Tym bardziej, że taki sposób mrożenia wstrzymuje wprowadzanie
> nowych rzeczy do repozytorium.

Rób to na branchu. Już nawet wiadom że dobrze żeby ten branch nazywał się
DEVEL. Coś nadal w tej sytyuacji twiewrdzić będziesz że coś Cie tu 
powsztymuje ? :)

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*



Więcej informacji o liście dyskusyjnej pld-devel-pl