piątek, 27 sierpnia 2021 o 17:57:26 UTC+2 Robert Magdziarz napisał(a):
> piątek, 27 sierpnia 2021 o 17:13:08 UTC+2 heby napisał(a):
> > On 27/08/2021 16:58, Robert Magdziarz wrote:
> > >> Sprawdź co robisz w tych linijkach, które podpowiedział valgrind.
> > > kod wygląda ok
> > Zaryzykuje, że urwalo Ci gdzieś referencje. Valgrid raportuje podobne
> > rzeczy w przypadku std::string const& getTempValue(); czyli to co
> > zostanie zwrócone jest czasami jeszcze troche działające i wylatuje
> > później, przy dalszych operacjach.
> wydaje mi się że wszystko jest dobrze
> poza tym wymienione wiersze kodu nie należą do wspomnianego "wadliwego" algorytmu,
który mam poprawić

Jeżeli owe wiersze kodu są uruchomione przed odpaleniem Twojego algorytmu, to mogą
coś napsuć w stanie programu. Urok takich języków jak C polega na tym, że możesz
sobie niechcący nadpisać jakiś losowy fragment pamięci, co może później mieć zupełnie
katastrofalne skutki.

(W sumie jeżeli nawet są uruchomione po Twoim algorytmie, ale zanim uzyskasz dostęp
do pliku, to też się mogą wydarzyć dziwne rzeczy, ale tutaj wygląda na to, że sam
plik jest generowany prawidłowo)

do góry

> Co za kompletna bzdura. "Praca" z zipami to koszmar do którego nikt
> normalny nie chce wracać. Zipy to się mogą co najwyżej tworzyć z
> automatu ale lepiej żeby nikt nie musiał nigdy do nich zaglądać.

A czemu nie zaglądać? Bo wstyd patrzeć? Przecież tam jest dokładnie to samo, co w
historii commitów gita. Ten sam syf.
Właśnie o to chodzi. Git może dać inną prezentację, ale informacja jest ta sama.

A jak się rozpakuje zipa w osobnym katalogu, to mamy równocześnie dostępne pliki z
jednego punktu w historii projektu. Jeśli ktoś korzysta z nawigacji w IDE, to ta
nawigacja działa. Jeśli w projekcie są media, to można je zobaczyć/przesłuchać. Itd.
To jest komfort pracy daleko wykraczający poza tekstowy diff, nawet taki kolorowy. A
jak mam robić git checkout do osobnego katalogu, żeby w pełnym komforcie obejrzeć
różnice (niekoniecznie tekstowe), to to jest ten moment, w którym wartość dodana
lokalnego gita wynosi epsilon. Git służy do synchronizacji zmian i tylko tam ma
wartość dodaną. Jak jest jedno "repo", to git nic nie wnosi.

Git ma jeszcze jedną smutną wadę. Otóż jego historia zmian ciągle rośnie (chociaż jej
użyteczność wcale nie, bo zwykle potrzebne jest tylko jakieś ostatnie okno czasowe a
nie całość) - a backup takiego repo staje się z czasem coraz bardziej uciążliwy.

--
Maciej Sobczak * http://www.inspirel.com

do góry

> Napisał kolega, że "potrafią zupełnie naturalnie zrobić backup". Na to
> ja odpowiadam, że nie - nie potrafią.

No tak. Ostatecznie to jeden z kilku etapów.

> A pendrive nie załatwi sprawy, z tego prostego powodu że nie jest
> geograficznie odległy.

To zależy, jaką sprawę chcesz załatwić. Jest nieskończenie bardziej odległy od
lokalnego repo. Nawet jak leży obok.

> > A jeśli nie chcę na "jakiś serwer"? Czemu wszyscy mają obsesję na
> > punkcie wysyłania swojej pracy na "jakiś serwer"?
> Bo to podstawa sensownego backupu.

Kiedyś trzymałem swoje pliki na "jakimś serwerze", gdzie admini zadbali o backup
serwerów w taki sposób, że serwery nawzajem trzymały swoje kopie. Przyszedł wirus
NIMDA i pozamiatał całą serwerownię. Dobrze, że miałem kopię u siebie.
Każde rozwiązanie ma swoje anegdoty.

> Zerknąłem na moją pierwszą z brzegu gierkę:
> http://simplesok.sf.net/
> Wielkość trunka 5 MiB. Po skompresowaniu zipem 3.8 MiB. Razy 109
> rewizji, to już ponad 400 MiB... Ok,

No właśnie, to jest dobry przykład. Bo ani 400MB to nie jest temat (najmniejszy
pendrive dostępny w sklepie jest kilkadziesiąt razy większy), ani też wcale nie
potrzebujesz tych 109 rewizji. Najważniejsza jest ostatnia, potem (dalej wstecz) ich
wartość użytkowa maleje w błyskawicznym tempie.

> A mi to się zdarzyło co najmniej kilka razy. Głównie w ramach szukania
> jakiegoś błędu i zastanawiania się dlaczego w pliku bb.c zmieniłem x=1
> na x+=1 i w jakich okolicznościach do tego doszło.

No właśnie. I jeśli masz dokumentację albo chociaż komentarze w kodzie, to nie
potrzebujesz historii, żeby na to pytanie odpowiedzieć. A jeśli nie masz, to nawet
109 rewizji, gdzie w 75 pojawia się x+=1, dalej będzie zagadką.

> filtr oleju w aucie odkręcam nie (jakże uniwersalnym) młotkiem, tylko
> wyspecjalizowanym do tego narzędziem.

Zip służy do archiwizacji.

--
Maciej Sobczak * http://www.inspirel.com

do góry

W dniu 28.08.2021 o 21:46, Maciej Sobczak pisze:
>> Co za kompletna bzdura. "Praca" z zipami to koszmar do którego nikt
>> normalny nie chce wracać. Zipy to się mogą co najwyżej tworzyć z
>> automatu ale lepiej żeby nikt nie musiał nigdy do nich zaglądać.
> A czemu nie zaglądać? Bo wstyd patrzeć? Przecież tam jest dokładnie to samo, co w
historii commitów gita. Ten sam syf.
> Właśnie o to chodzi. Git może dać inną prezentację, ale informacja jest ta sama.

> A jak się rozpakuje zipa w osobnym katalogu, to mamy równocześnie dostępne pliki z
jednego punktu w historii projektu. Jeśli ktoś korzysta z nawigacji w IDE, to ta
nawigacja działa. Jeśli w projekcie są media, to można je zobaczyć/przesłuchać. Itd.
To jest komfort pracy daleko wykraczający poza tekstowy diff, nawet taki kolorowy. A
jak mam robić git checkout do osobnego katalogu, żeby w pełnym komforcie obejrzeć
różnice (niekoniecznie tekstowe), to to jest ten moment, w którym wartość dodana
lokalnego gita wynosi epsilon. Git służy do synchronizacji zmian i tylko tam ma
wartość dodaną. Jak jest jedno "repo", to git nic nie wnosi.

Brzmi jak opinia kogoś kto gita zna tylko z opowiadań. Też kiedyś
używałem zipów, potem wykupiłem nawet jakieś narzędzia, które takie
porównywanie wersji ułatwiały. A potem poznałem gita i od tego czasu
nigdy z tych narzędzi ani z zipów nie skorzystałem. Teraz kilkoma
kliknięciami sprawdzam co w danym okresie zmieniłem, po co to zmieniłem,
przełączam się między feature branchami żeby nie musieć mieć x kopii
tego samego projektu na dysku, dodaje taga wywołującego automatyczny
deploy i robię milion innych rzeczy. Miałbym po nieudanych zmianach w
kodzie szukać w którym zipie mam poprzednią wersję? W sumie to są takie
oczywistości, że aż dziwnie tłumaczyć.

do góry

On 28/08/2021 21:46, Maciej Sobczak wrote:
>> automatu ale lepiej żeby nikt nie musiał nigdy do nich zaglądać.
> A czemu nie zaglądać? Bo wstyd patrzeć?

Bo miejsca na dysku szkoda.

> Przecież tam jest dokładnie to samo, co w historii commitów gita. Ten sam syf.

Jesli kto ma syf.

> Właśnie o to chodzi. Git może dać inną prezentację, ale informacja jest ta sama.

Nie jest ta sama. Ogólnie VCS dorobiły się znaczących usodkonaleń od lat
60-tych. Może warto ponownie sprawdzić, co nowego w informtyce, wydajesz
się być jakiś odmrożony z czasów Elvisa. Współczesne VCS pomagają w
nawigacji zmian w kodzie źródłowym. Twóje ZIPy z porównywarką nie mają
nawet śladowej funkcjonalnosci tego typu.

> A jak się rozpakuje zipa w osobnym katalogu, to mamy równocześnie dostępne pliki z
jednego punktu w historii projektu.

A jak się zrobi checkout...

Ale moment, ludzie nie są aż tak głupi. Najzwyczajniej robią switch.
Zajmuje to 2-3 sekundy. Albo check for modifications. Albo blame. Zależy
co chcą znaleźć.

> Jeśli ktoś korzysta z nawigacji w IDE, to ta nawigacja działa.

Zupełnie jak w VCS.

> Jeśli w projekcie są media, to można je zobaczyć/przesłuchać.

Zupełnie jak w VCS.

> Itd. To jest komfort pracy daleko wykraczający poza tekstowy diff, nawet taki
kolorowy.

Oczywisćie, to komfort daleko wykraczajacy poza pojęcie komfotu.
Nazwałbym to mordęgą, rozpakowywanie 70 ZPIów, aby stwierdzić kiedy
zmieniła się linika numer 10345 w pliku main.cpp. U mnie zajmuje to sekundy.

> A jak mam robić git checkout do osobnego katalogu, żeby w pełnym komforcie obejrzeć
różnice (niekoniecznie tekstowe)

Na SVN oglada je bez zrzucania plików lokalnie. Zdalnie. Co powiesz na
taką innowację z cuting edge VCS? Komfort nawet pełnieszy - jest np.
blame. Zawze możesz sobie zrobić checkout, choć nie pamiętam, abym tego
kiedykowleik miał potrzebę użyć w celu porównania czegokolwiek.

>, to to jest ten moment, w którym wartość dodana lokalnego gita wynosi epsilon.

Najzwyczajniej nigdy nie pracowałeś w jakimkolwiek projekcie z VCS.
Nawet git, którego nie lubie nawet bardziej niż svn, jest <bład:
dzielenie przez zero> lepszy od ZIPów.

> Git służy do synchronizacji zmian i tylko tam ma wartość dodaną. Jak jest jedno
"repo", to git nic nie wnosi.

Nie pojmujesz jak wygląda typowy flow pracy w zespole. Nic dziwnego, że
gadasz głupoty. Systemy kontroli wersji to nie system archiwizacji
wersji. Tylko *kontroli*. To coś innego.

> Git ma jeszcze jedną smutną wadę. Otóż jego historia zmian ciągle rośnie (chociaż
jej użyteczność wcale nie, bo zwykle potrzebne jest tylko jakieś ostatnie okno
czasowe a nie całość) - a backup takiego repo staje się z czasem coraz bardziej
uciążliwy.

Zastanów się jak bardzo uciązliwy jest backup repo SVN majacego 15 lat i
30GB kodu źródłowego w trunku + ze sto tyś branchy. Czy tak bardzi
uciążliwy, że siedzi nad tym biblion ludzi przepisujac repo na kartki,
czy może jednak technologia ma rozwiązanie pozwalajace jakos to ogarnąć
automatycznie i bez awari przez ten cały czas? By chyba nie myslisz, że
ktoś to pakuje do ZIPa i nagrywa na CDki...

do góry

> Brzmi jak opinia kogoś kto gita zna tylko z opowiadań.

Jesteś profilerem brzmieniowym?

> Też kiedyś
> używałem zipów, [...] A potem poznałem gita i od tego czasu
> nigdy z tych narzędzi ani z zipów nie skorzystałem.

No widzisz, to jest najfajniesza część. Też byłem na etapie zachwytu nad gitem. Teraz
jestem na tym następnym.
Bo to jest trochę jak tutaj:

https://www.reddit.com/r/aoe2/comments/8jvz1a/what_i
s_a_noob_comprehensive_framework_and/

;-) ;-) ;-)

> przełączam się między feature branchami

No właśnie. To jest ta część gita, która mnie najbardziej wkurza. Kto w ogóle
wymyślił to *przełączanie*? Od przełączania są okna na ekranie a nie jakieś jedno i
to samo miejsce w strukturze katalogów na dysku.
Ja chcę mieć kilka rzeczy dostępnych *równocześnie*. I nie, w normalnych programach
nie robię "commita", żeby przełączyć się do drugiego okienka.

$ git checkout myfeature
error: Your local changes to the following files would be overwritten by checkout:
...
Please commit your changes or stash them before you switch branches.
Aborting
$

Poważnie?

> Miałbym po nieudanych zmianach w
> kodzie szukać w którym zipie mam poprzednią wersję?

Jeśli nie wiesz, w którym pliku co masz, to bida. Taka ogólna.

> W sumie to są takie
> oczywistości, że aż dziwnie tłumaczyć.

Wykres i tabelka ze strony powyżej. ;-)

--
Maciej Sobczak * http://www.inspirel.com

do góry

> Na SVN oglada je bez zrzucania plików lokalnie. Zdalnie. [...]
> Nie pojmujesz jak wygląda typowy flow pracy w zespole.

Czyli gadamy sobie na różne tematy. Od jakiegoś czasu rozważamy temat użytkowania VCS
*lokalnie* i *jednoosobowo*.
Pomyliłeś dyskusje, stąd nieporozumienie.

> Systemy kontroli wersji to nie system archiwizacji
> wersji. Tylko *kontroli*. To coś innego.

To też ciekawe rozróżnienie. Bo ja dodatkowo jeszcze odróżniam "control" od
"tracking". Ale nie ma to wielkiego znaczenia przy pracy *lokalnej* i
*jednoosobowej*.

> Zastanów się jak bardzo uciązliwy jest backup repo SVN majacego 15 lat i
> 30GB kodu źródłowego w trunku + ze sto tyś branchy.

Każdy problem ma swoje rozwiązanie, odpowiednim kosztem. Pytanie, jaki problem chcemy
mieć. Czasem racjonalnie można wybrać mniejszy i o tych wyborach tutaj rozmawiamy.

--
Maciej Sobczak * http://www.inspirel.com

do góry

W dniu 29.08.2021 o 20:39, Maciej Sobczak pisze:
>> Brzmi jak opinia kogoś kto gita zna tylko z opowiadań.
> Jesteś profilerem brzmieniowym?
Akurat nie tylko ja to zauważyłem.
>> Też kiedyś
>> używałem zipów, [...] A potem poznałem gita i od tego czasu
>> nigdy z tych narzędzi ani z zipów nie skorzystałem.
> No widzisz, to jest najfajniesza część. Też byłem na etapie zachwytu nad gitem.
Teraz jestem na tym następnym.

Ja na etapie zachwytu byłem kilka lat temu. W międzyczasie poznałem też
trochę wad. I nie trafiłem na wadę która by w jakimkolwiek stopniu
przysłoniła zalety. Ale jak kto woli. Można używać notatnika a wersje
kodu trzymać na odpowiednio opisanych dyskietkach.

do góry

On 29/08/2021 20:57, Maciej Sobczak wrote:
>> Na SVN oglada je bez zrzucania plików lokalnie. Zdalnie. [...]
>> Nie pojmujesz jak wygląda typowy flow pracy w zespole.
> Czyli gadamy sobie na różne tematy. Od jakiegoś czasu rozważamy temat użytkowania
VCS *lokalnie* i *jednoosobowo*.

Dokładnie tak. Kiedy pracujesz zespole z uzyciem VCS, jego przydatnośc
okazuje się tak duża, że stosujesz go w zyciu "prywatnym". Osobicie mam
postawiony SVN w domu. Do małych, duperelowatych projekcików stosuje
dokładnie te same metody pracy, co w zespole. Ułatwiają życie. Nie tylko
mi. Kilka osób z mojego otoczenia postawiło sobie różne VCS w domu,
wliczając to trzymanie tam prywatnych programów, list zakupów, podań do
spółdzielni, telefonów do lekarzy. Niektórzy nawet przećwiczyli
domowników w ich używaniu. Masz dwa wyjścia: albo to idioci, albo ZIPy
są idityczne.

Z powodu mozliwoci stworzenia repozytorium jednym kliknieciem, nie ma
nawet argumentu że to trudne. To trywialne. Dlaczego więcenie używać?
Nie wszyscy są tak głupi, aby uwierzyć w "traumatyczne robienie branchy
w SVN".

Postawienie SVNa na apache2 jest tak proste, że aż wstydliwe, choć
trzeba poza klikaniem wciskać klawisze. Raz na parę lat. Faktycznie,
dramat. Stworzenie repo w katalogu na dysku lokalnym to 1 kliknięcie.
Nie ma argumentu przeciwko.

> Pomyliłeś dyskusje, stąd nieporozumienie.

To nie jest nieporozumienie. Najzwyczajniej nie rozumiesz po co komu
VCS. Wniosek z tego: nie pracowałeś w zespole. Inaczej nawyki
przenikneły by do częsci prywatnej. Czy to dupna aplikacja czy nastepny
program do rysowania choinki na zaliczenie - w obu przypadkach VCS
będzie lepszym wyborem niż idityczne ZIPy.

>> Systemy kontroli wersji to nie system archiwizacji
>> wersji. Tylko *kontroli*. To coś innego.
> To też ciekawe rozróżnienie. Bo ja dodatkowo jeszcze odróżniam "control" od
"tracking". Ale nie ma to wielkiego znaczenia przy pracy *lokalnej* i
*jednoosobowej*.

Tracking/conrol samego siebie jest równie ważny co tracking/control
kolegów. Po kilku latach nie ma żadnej różnicy kto napisał daną linijkę
kodu. Ważne, że wiadomo po co ją napisano, kiedy ją napisano i co
zmieniono przy okazji. Ta wiedza, pod warunkiem nie posiadania "syfu",
jest w repozytorium VCS. Ale nie ma jej w ZIPach. w ZIPach nic nie ma
poza archiwami i skranie nieskuteczną metodą prowadzenia śledztwa.

>> Zastanów się jak bardzo uciązliwy jest backup repo SVN majacego 15 lat i
>> 30GB kodu źródłowego w trunku + ze sto tyś branchy.
> Każdy problem ma swoje rozwiązanie, odpowiednim kosztem.

Zaczynasz bredzić. Kosztem? Zastanówmy się: firma ma koszt w postaci
sensownego NASu i backupów. W domu stosujesz ze dwa skrypty do
automatycznego backupu repo np. na google drive. Czy tu czy tu, problem
jest albo w jakosci hardewareowych rozwiązań, albo w sprycie usera. Oba
mają za zadanie utrzymać kilka plików w rozsądnym stanie. Potrafimy
utrzymywać pliki w rozsądnym stanie od lat 80, co najmniej. Ba, dostępne
jest to dla domowego usera prawie za darmo. To jest ten "odpowiedni
koszt" po którym wszystkim mają wypoaść pety z gęby z wrażenia jakie
drogie jest utrzymanie w domu SVN/git/whatever?

> Pytanie, jaki problem chcemy mieć.

Posiadanie setki paczek ZIPa to *jest* problem sam w sobie. Przy nim,
duperela jak backup repozytorium, jest nieistotna. SVN nie ma żadnych
wad, o których w tym wątku bredzono. Ma inne, które nie padły. Wniosek z
tego że ludzie piszą o problemach, których sami nie doświadczyli. Za to
pojawia się ZIP, który nie ma śladu zalety, same wady i stawia się go w
alternatywie dla roziązań milion razy lepszych, prostzych i
funkcjonalnych. Piłeś? Nie pisz.

> Czasem racjonalnie można wybrać mniejszy

ZIPy nie są *alternatywą* do czegokolwiek. Go gówno. Oferujesz do
zastosowań domowych gówniany sposób "kontroli" wersji i tylko mniej
gówniany sposób "archiwizacji", mimo że argumenty o kłopotliwości
przeciętnego VCS są najzwyczajniej zmyślonym bredzeniem osoby która nie
ma pojęcia jak działają w praktyce, czy to dużej firmy czy przeciętnego
Janusza programowania. ZIPy nie są alternatywą. To najgorsze gówno w
jakie można wdepnąć jako programista. Najzwyczajneij wszytkie inne
rozwiązania są o kilometr dalej w rozwoju i wygodzie. Uznałbym że to
prowokacja, ale coś czuje, że nie tym razem.

do góry

2021-08-29 o 23:26 +0200, heby napisał:
> Postawienie SVNa na apache2 jest tak proste, że aż wstydliwe, choć
> trzeba poza klikaniem wciskać klawisze.

Rozumiem, że stawiasz na apache2. Zapytam, bom ciekaw - dlaczego?
Testowałem onegdaj kilka sposobów instalacji svn, i w wariancie z
apache nie udało mi się znaleźć żadnej wartości dodanej w porównaniu do
ssh, za to trzeba męczyć się z niepotrzebnym, publicznym httpd.

No chyba, że z jakichś (innych) powodów masz już swoje PKI i we
wszelkich interfejsach uwierzytelniasz użytkowników za pomocą osobowych
x509. Czy to ten przypadek?

Mateusz

do góry