Mateusz Viste <m...@x...invalid> wrote:
> 2022-07-20 o 14:54 -0000, a...@m...uni.wroc.pl napisa?:
> > Gwoli malego wyjasniena: kazda wersja to logicznie w miare
> > jednorodna i kompletna zmiana, ktora sie kompiluje i przeszla
> > wszystkie testy. Experymentalny kod i wersje robocze _nie_
> > umieszczam w systemie kontroli wersji
>
> Kiedy trunk to w?a?nie z za?o?enia jest wersja robocza.

Jak chcesz mozesz go nazwac wersja robocza. Ale u mnie
trunk ma sie kompilowac i przejsc testy, a wersja robocza
to niekoniecznie.

> To, o czym
> piszesz to tagi. Je?li nie trzymasz kodu roboczego w VCS to tracisz
> granularn? widoczno?? na wprowadzone zmiany - widzisz tylko jeden
> wielki changelog kodu z jednej publicznej wersji do drugiej.

Granularnosc mam taka jaka chce i potrzebuje. Jak np. dodaje
plik z nowymi funkcjami to moge go pisac funkcja po funkcji
i rozne posrednie wersje istnieja po pare minut. W system
kontroli wersji plik umieszczam jak jest w miare kompletny.
Albo np. zmiana jednej konstrukcji na inna w calym kodzie,
to moge robic plik po pliku, testujac etapy posrednie
a do systemu wersji idzie calosc. Czasami zmiana jest
malutka: poprawka moze sie sprowadzac do zamiany jednej
linii kodu (+ testy i pozycja w ChangeLog). Czasami
zmiana nie dziala z powodu bledu w innej czesci kodu,
wtedy zmiana moze czeka na to az ta inna czesc bedzie
poprawiona. Experymentalna wersja moze byc tylko po
to zeby zobaczyc jaki bedzie efekt zmiany.

> Dlaczego
> tak? Nie umiem dostrzec zalet takiego dzia?ania, a wad sporo - cho?by
> brak mo?liwo?ci automatyzacji procesu kompilacji i test?w.

Pelna kompilacje i normalne testy robi 'make' i dla mnie jest
to wystarczajaco zautomatyzowane. Ok, jest jeden problem:
testy sobie chodza automatycznie, ale dla sporej czesci musze
popatrzec na wynik by wiedziec czy jest poprawny. Ale to
jest zupelnie niezalezne od tego jak uzywam system kontroli
wersji, po prostu trzeba by zautowatyzowac kryteria poprawnosci
a tu sa subtelnosci (co jest latwe to jest zautomatyzowne, ale
musze patrzec na klopotliwe przypadki). Przy pracy nad wersjami
roboczymi czesto uzywam kompilacje przyrostowa, tu polecenia kompilacji
sa podawane recznie. Zaleta jest taka ze kompilacja przyrostowa
jest znacznie szybsza niz uzycie 'make' (zwykle
wystarczy rekompilacja malego kawalka, ale czasami trzeba
rekompilowac duzo wiecej i regula dla 'make' jest konserwatywna,
tzn. obsluguje najgorszy przypadek). Przy tym jest to cecha
jezyka, gdyby kod byl w C to "optymalna" rekompilacje robilby
'make' (ale ten "reczny" wariant pozwala na rekompilacje +
prosty test ponizej 2s, w C + 'make' test bylby bardziej
klopotliwy).

> U mnie system
> buildowy jest podpi?ty pod svn, i ka?dy commit wywo?uje build i testy,
> dzi?ki czemu wi?kszo?? regresji mo?na wychwyci? na bardzo wczesnym
> etapie.

Hmm, ja _nie_ chce blednych wersji w systemie kontroli wersji.
Dlatego commit jest dopiero _po_ kompilacji i testach.
Teoretycznie mozna system kontroli wersji skonfigurawac tak
zeby wlasciwy commit zaszedl tylko jak przejda testy. Ale
jak cos robie to chce wiedziec ze skonczylem, czyli w
praktyce tak czy siak czekalbym na zakonczenie testow.

--
Waldek Hebisch