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