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

do góry

W dniu 2022-07-20 o 13:55, heby pisze:

> 1) Możesz zainstalować oprogramowanie TortoiseSVN.
> 2) W nim możesz postawić bazę danych subverion, za pomocą 2 kliknięć w
> pustym katalogu (Create reposistory here)
> 3) Od tej porty ten "katalog" jest Twoim "serwerem". Adres to file://siezka
> 4) Dzięki temu możesz się bawić do woli i psuć co chcesz
> 5) W razie czego zawartośc tego katalogu z bazą danych należy backupować

Rozumiem, że robiąc backup jednego dnia poprzedni mogę już zniszczyć -
to nie ja mam dbać o historię.
P.G.

do góry

On 20/07/2022 20:29, Piotr Gałka wrote:
>> 1) Możesz zainstalować oprogramowanie TortoiseSVN.
>> 2) W nim możesz postawić bazę danych subverion, za pomocą 2 kliknięć w
>> pustym katalogu (Create reposistory here)
>> 3) Od tej porty ten "katalog" jest Twoim "serwerem". Adres to
>> file://siezka
>> 4) Dzięki temu możesz się bawić do woli i psuć co chcesz
>> 5) W razie czego zawartośc tego katalogu z bazą danych należy backupować
>
> Rozumiem, że robiąc backup jednego dnia poprzedni mogę już zniszczyć -
> to nie ja mam dbać o historię.

Repozytorium ma być wieczne. Trzyma cała historię, od zawsze.

Backupy mają być odzyskiwalne.

Sam decydujesz ile % pewnosci wkładasz w swoje backupy.

Ja, w przypadkach tego typu, trzymam po kilka backupów na róznych
nośnikach, i nie kasuję starych jak nie muszę.

Ponadto sprawdzam, czy backup da się odzyskać. To bardzo ważne.

Paranoicznie czasami dodaje md5, bo miałem nieprzyjemne problemy z
kablami sata.

Zamiast robić backupy codziennie - może warto zainwestować w hardware
który zapewnia sensowny poziom bezpieczeństwa danych? Wiele NASów ma
możliwośc wsadzenia kilku dysków w "jakimś raidzie". Nie twierdze, że to
super rozwiązanie, ale lepsze niż brak jakiegokolwiek. Paranoicznie
można nawet uzywać zfs z automatycznymi sumami kontrolnymi... ale to
może przesada.

do góry

On 20/07/2022 20:29, Piotr Gałka wrote:
> Rozumiem, że robiąc backup jednego dnia poprzedni mogę już zniszczyć -
> to nie ja mam dbać o historię.

Jeszcze uwaga: nie traktuj rozwiązania z "Create repository here" jako
docelowego. To raczej miejsce do orientacji czy ma to sens. Prawidłowo
powinieneć mieć serwer sieciowy z repozytorium dostępnym protokołem
svn://. Głównie dlatego, że będzie ono znacznie bezpieczniejsze. Pliki
na dysku możesz przypadkiem skasować jako repo. Repozytorium svn:// na
osobnej maszynie raczej przypadkiem nie uszkodzisz, a jeśli zmienisz coś
źle, zawsze możesz wycofać zmianę. Tylko że to inny poziom trudności i
dlatego nie warto zaczynać z tego miejsca.

Jeśli chcesz sprawdzić subversion i TortoiseSVN to daj znać - poprowadzę
Cię za rękę krok po kroku co wyklikać. To jest trywialne, ale za
pierwszym razem może być mniej oczywiste.

do góry

środa, 20 lipca 2022 o 20:37:46 UTC+2 heby napisał(a):
> Paranoicznie czasami dodaje md5, bo miałem nieprzyjemne problemy z
> kablami sata.

O, a co się może dziać przez kable sata?
Mój dysk SATA od jakiegoś czasu (po 15 latach) zaczyna głupieć - ale przez jakiś czss
po resecie jest OK, ostatnim razem po 91k sekund, ale dziś już po 17k.
dmesg zawiera informacje o resecje sata, a dysk roni brzydki bzyk głowicami, jakby
walił w obudowę.
Ale odczyty i zapisy w końcu się udają, choć sync potrafi sprawy nie załatwić i po
resecie wymaga ręcznego fsck.

do góry

W dniu 2022-07-20 o 20:42, heby pisze:

> Jeśli chcesz sprawdzić subversion i TortoiseSVN to daj znać - poprowadzę
> Cię za rękę krok po kroku co wyklikać. To jest trywialne, ale za
> pierwszym razem może być mniej oczywiste.

Zapisałem sobie wszystko co ważne w pliku wsadzonym do kartoteki
podlegającej backupowaniu.

U mnie od rozważenia czegoś do decyzji mija zazwyczaj sporo czasu.
Na razie wykorzystałem okazję aby zdobyć trochę wiedzy o czymś o czym
nie miałem pojęcia.

W tym tygodniu miałem pilnie coś zrobić (pierwsza płytka po
przeniesieniu się do KiCad V6) na czwartek (promocja w Techno-service).
A tymczasem poniedziałek i wtorek zeszedł ma na p.m.e.
Choć to malutka płytka to nowe footprinty itp. Choć dziś już się za to
wziąłem to jeszcze nie skończyłem.

Kiedyś siedziałem w samochodzie koło 9-latka, który czytał "Tajemniczą
wyspę" Verne'a. Bardzo szybko się przekonałem, że ja czytam 6x wolniej
od niego. Takie czytanie/pisanie na p.m.e pochłonęło mi 100% czasu.

Pamiętam o Tobie. Już parę razy różnych rzeczy się od Ciebie
dowiedziałem. Według mnie 'masz swoje za uszami' ale dajesz się lubić :)
Wydaje mi się, że ja nigdy nie twierdziłem / twierdzę / stwierdzę, że
coś wiem, gdy tego nie wiem na 100% i dlatego chyba mnie tolerujesz :)

Nie lubię nagabywać kogoś o coś. Jak mam pytanie to wolę zapytać na
grupie - wtedy nikogo nie przymuszam do angażowania się. Kto chce może
się odezwać.
Ale bardzo dziękuję za deklarację!

Tylko, że przy moim programowaniu (góra miesiąc w roku) to mam
podejrzenie, że system kontroli wersji to trochę aż na wyrost. Wprawdzie
lubię robić różne nowe rzeczy, ale ostatnio jestem strasznie zarobiony.
Między innymi przez braki na rynku. Co rusz spada na mnie rozwiązywanie
problemów typu - tego nie możemy dostać - co robimy. I muszę wyważać
otwarte drzwi - jak inaczej nazwać projektowanie tego samego na innych
podzespołach tylko dlatego, że te oryginalnie użyte mają być dostępne za
rok.
Ta płytka na jutro też w ogóle by nie powstawała gdyby nie to, że
jakiegoś procesora nie da się dostać.
P.G.

do góry

W dniu 2022-07-20 o 16:31, heby pisze:
> On 20/07/2022 16:09, Janusz wrote:
>>>> a siedzę w informatryce w zasadzie od początku
>>> To za słabo się przykładasz.
>> Informatyce, nie w programowaniu, nigdzie nie twierdziłem że jestem
>> programistą.
>
> To bardzo wiele wyjaśnia.
No to teraz ładnie przeproś :)

--
Janusz

do góry

On 20/07/2022 21:57, Janusz wrote:
>>> Informatyce, nie w programowaniu, nigdzie nie twierdziłem że jestem
>>> programistą.
>> To bardzo wiele wyjaśnia.
> No to teraz ładnie przeproś :)

Zaraz po tym jak określisz dlaczego dynamiczny polimorfizm działa na
moim Harvardzie.

do góry

On 20/07/2022 21:52, Dawid Rutkowski wrote:
>> Paranoicznie czasami dodaje md5, bo miałem nieprzyjemne problemy z
>> kablami sata.
> O, a co się może dziać przez kable sata?

Naiwnie zakładałem że nic. Przecież transmisje są z sumami kontrolnymi
od czasu UDMA133.

A dzieje się coś takiego:
1) zapisuje grzecznie
2) kabel ma *nagle* jakiś problem
3) w dmasg widzę tysiace komunikatów "dma error, ble ble, retrying".
4) po chwili pliki uszkodzone bo kernel się poddał i nie zapisał
jakiegoś bloku.

Wymieniłem kabel w akcie desperacji i nagle wszystko działa.

Wniosek: sumy kontrolne to fajna sprawa, ale istnieje limit zapisów ze
zła sumą kontrolną...

do góry

On 20/07/2022 21:56, Piotr Gałka wrote:
> Kiedyś siedziałem w samochodzie koło 9-latka, który czytał "Tajemniczą
> wyspę" Verne'a. Bardzo szybko się przekonałem, że ja czytam 6x wolniej
> od niego. Takie czytanie/pisanie na p.m.e pochłonęło mi 100% czasu.

:) Moja ulubiona ksiązka Verne. Być może ulubiona w ogóle ;)

To jedyna ksiązka z dzieciństwa, w której pozytywny bohater jest ścisły :)

> Pamiętam o Tobie. Już parę razy różnych rzeczy się od Ciebie
> dowiedziałem. Według mnie 'masz swoje za uszami' ale dajesz się lubić :)

Pamiętaj, że jestem złośliwy tylko, jesli ktoś mnie puknie kijem bez
przyczyny.

> Nie lubię nagabywać kogoś o coś.

To źle. Ogólnie ludzie w IT lubią dzielić się wiedzą. "Szkolenia z
subversiona" realizowałem praktycznie co chwile z racji zawodu, więc
niejako pojmuję czego kto nie pojmuje statystycznie najczęsciej i gdzie
są niejasności.

> Tylko, że przy moim programowaniu (góra miesiąc w roku) to mam
> podejrzenie, że system kontroli wersji to trochę aż na wyrost.

Widzisz, problem nie w tym, abyś go użył. Możesz pomarudzić, że to
głupie i nigdy nie użyć. W pełni to rozumiem.

Rzecz w tym, aby pojmowac, że ma się alternatywę. Nie ma nic gorszego
niż beton w poglądach na to że "tak jak robie jest najlepiej, bo tak
robię od 30 lat". W embedded takich sytuacji jest ogramna ilość. Nie
wiem, dlaczego to środowisko jest takie specyficzne, ale praktycznie
wszystkie anegdoty i opowieści zasłyszane, dotyczące średniowiecza
narzędziowego, dotyczą embedded. Nawet duże korpo potrafią wstydliwie
chować pakowanie źródeł do ftp jako substytut systemów kontroli wersji.
Mam wrażenie, że nie ma przepływu wiedzy pomiędzy programistami dużych
komputerów a embedded. Środowiska odizolowane od siebie i w dodatku
obrażone. Nie mieszają się. A to mieszanie jest krytyczne ważne. Nic tak
nie cieszy, jak ktoś, kto pokaze mi, że można zrobic coś *lepiej* niż ja
potrafię. A to się dzieje codziennie w moim wypadku.

Jesli nawet z tego mieszania nic nie wyjdzie i zostaniesz z tym co masz,
nic straconego. Może inni, czytający te wypociny obok, zainteresuja się
tematem.

> Ta płytka na jutro też w ogóle by nie powstawała gdyby nie to, że
> jakiegoś procesora nie da się dostać.

Swoją drogą chińczycy skopiowali STM32 bit-w-bit i noga-w-nogę i nazwali
bodaj GD32. Moze i z Twoim procesorem zrobili to samo?

do góry