On 25/08/2021 09:53, Mateusz Viste wrote:
>> On 24/08/2021 17:50, Maciek Godek wrote:
>>> Pamiętam, że kiedyś robiłem brancha na SVNie i to był koszmar.
>> U mnie trwa około 2 sekund.
> Bo tu oczywiście nie chodziło o branch, tylko o merge. :)

Super. Coś koło 4-5 sekund.

> Te bywają długawe

Tak, czaami nie zdążę siorpnąc herbatki.

>> Repo takie sobie, około miliona plików źródłowych i ponad 30GB
>> gołego mięska na trunku/tagu z którego robie
> Ładnie. Zerknąłem na swoje największe repo - ledwo 100 tys. plików w
> trunk, niecałe 7 GiB danych, 30 tys. rewizji, ok 12 lat pracy. W tym
> czasie liczba napotkanych problemów: zero. Dlatego rozbawiły mnie nieco
> te historie o "długu technologicznym".

Ja wiem jakie problemy ma SVN, związane z realną pracą, ale w
bajkoopowieściach gitowców niegdy one nie padają. Padają różne brednie.

>> Jeśli masz zespół programistów na Antarktydzie na łaczach
>> wdzwanianych TePeSA to zaleta gita z offlinowym repo jest
>> zdecydowanie wyróżniająca go na tle tych normalnych potrzeb reszty
>> ludzkości.
> Muszę tutaj zaoponować - w takiej sytuacji prędzej czy później
> antarktyczni programiści będą musieli te swoje wszystkie commity i tak
> przepchać tym swoim telegrafem, więc oszczędność w git jest żadna.

Oszczęsdnośc polega na tym, że pośrednich komitów nie pchasz w sieć.

Przykładowo: odradzam używanie SVN w przypadku pracy z plikami binarnymi.

>> Na svn by go *naprawdę* nie było. Tak najzwyczajniej, w SVN nie ma
>> problemu z synchronizacją. O ile potrafisz go używać.
> "commit early, commit often". Niestety wielu ludzi ma z tym jakiś
> problem psychologiczny. Wstydliwość, czy nie wiem co. Może do nich
> właśnie przemawia to całe lokalne gitowanie...

Wypytuje zawsze dlaczego używaja gita. Odpowiedż w 80% wypadków taka
sama: bo ma lokalne repo. Ale nikt nie potrafi uzasadnić po co mu to
potrzebne. CHoć trafiają się argumenty antysocjalne i antyzespołowe
(nikt nie patrzy w to co robie).

>> Ilość userów nijak nie zwiększa problemów pracy SVN. Rozmiar repo też.
> Może zwiększać, przy patologicznej organizacji pracy (Janek i Zdziusiu
> pracują jednocześnie nad refaktoryzacją tej samej funkcji trunkowej).

Jeśli 100 osób na raz zmieniło tą tamą linijkę to i Święty Git nie pomoże.

>> Nie jestem zwolennikiem SVN
> Z ciekawości - dlaczego?

Z powodu kłopotów z backportowaniem poprawek. Nie jest to poprawnie
ogarniane. Co prawda dzięki temu mam czysty styl pracy (brak merge do
niższych rewizji wychodzi tylko na dobre) ale mimo to ludzie robią takie
błędy i SVN nie ma nic co by tutaj pomagało.

do góry

2021-08-25 o 10:02 +0200, heby napisał:
> On 25/08/2021 09:53, Mateusz Viste wrote:
> >> On 24/08/2021 17:50, Maciek Godek wrote:
> >>> Pamiętam, że kiedyś robiłem brancha na SVNie i to był koszmar.
> >> U mnie trwa około 2 sekund.
> > Bo tu oczywiście nie chodziło o branch, tylko o merge. :)
>
> Super. Coś koło 4-5 sekund.

Dzisiaj, tak. Dlatego pisałem, że to żaden koszmar, choć jeśli kolega
Maciek eksperymentował z svn w latach 200x, to mógł zaobserwować
gorsze wyniki. Ale nie wiem czy faktycznie się na tym przejechał, czy
po prostu tak przeczytał na jakimś forum i pomyślał że to fajny
argument - wszak taki mechanizm jest mi również znany.

> > Te bywają długawe
>
> Tak, czaami nie zdążę siorpnąc herbatki.

Do herbatki to służy przecież kompilacja a nie merge. Sądziłem, że w
naszej branży to oczywistość (ref: xkcd, "compiling!"). :-)

> > Muszę tutaj zaoponować - w takiej sytuacji prędzej czy później
> > antarktyczni programiści będą musieli te swoje wszystkie commity i
> > tak przepchać tym swoim telegrafem, więc oszczędność w git jest
> > żadna.
>
> Oszczęsdnośc polega na tym, że pośrednich komitów nie pchasz w sieć.

Jak nie pcham, jak pcham. No chyba, że wcześniej skorzystam z zaklęć
rebase/squash/itd, ew. jakieś amendowanie... ale to należałoby uściślić.
I faktycznie - svn takich mechanizmów nie posiada. Bo i po co?
Repozytorium to nie konkurs artystyczny.

> Przykładowo: odradzam używanie SVN w przypadku pracy z plikami
> binarnymi.

Zdarza mi się (rzadko, ale jednak) trzymać pliki binarne w svn - czasem
do kilku MiB. Działa. Jeśli ktoś zmieni ten plik 10 razy, to svn up
zaciągnie mi tę ostatnią (najświeższą) wersję. Git natomiast będzie
pchał 10x więcej danych. Nie widzę w czym git tutaj lepszy. Abstrahuję
tu od dodatków typu LFS, bo to proteza której po prostu nie potrzeba w
svn.

> Z powodu kłopotów z backportowaniem poprawek. Nie jest to poprawnie
> ogarniane. Co prawda dzięki temu mam czysty styl pracy (brak merge do
> niższych rewizji wychodzi tylko na dobre) ale mimo to ludzie robią
> takie błędy i SVN nie ma nic co by tutaj pomagało.

A git ma? Pytam szczerze, bo nie wiem. Backporty mi się czasem
zdarzają. Typowo: przeportowanie jakiejś istotnej poprawki z wersji
14.x do dawnej wersji 13.x sprzed roku. To, co proponuje w tym
zakresie svn jest, jak dla mnie, zupełnie wystarczające. Oczywiście
zdarzają się sytuacje, w których svn nie wie jak ogarnąć jakiś merge bo
kod w międzyczasie uległ zbyt dużym zmianom. Ale to już klasa
problemów, których wg. mnie nie powinna próbować rozwiązać maszyna.
Jeśli przeklejenie kodu nie jest oczywiste to sprawę tak czy inaczej
powinien rozpatrzyć człowiek i podpowiedzieć automatowi co z czym ma
posklejać aby wynik miał szansę zadziałać (i tak dzieje się w svn).

Mateusz

do góry

On 25/08/2021 10:34, Mateusz Viste wrote:
> zdarzają. Typowo: przeportowanie jakiejś istotnej poprawki z wersji
> 14.x do dawnej wersji 13.x sprzed roku.

Mówie o backportowaniu podczas flow na branchu.

Przykład:

1) robie brancha z trunka
2) na trunku ktoś usuwa plik A i dodaje krytyczny ficzer
3) zaciągam do branch zmianę z 2)
4) ktoś rewertuje omyłkowo usunięty plik na trunku
5) ja merguje się z moim branchem do trunka
6) plik A znika

To jest backport do brancha w celu ponownego zespawania brancha z
trunkiem i to powoduje problemy. Co ciekawe, taki styl pracy jest
*oficjalnie* sugerowany przez Stefana. Mimo, że powoduje rozjazdy i
fałszywe konflikty. U mnie jest to zabronione. Zamiast backportu robie
*nowy* branch z trunka i przenoszę zmiany ze starego, co usuwa
*wszystkie* problemy z mergowaniem backportów, bo ich nie ma. I branch
nie z trunka, tylko taga, ale to by było zbyt skomplikowane dla opisu...
tak tylko dla purystów uwaga ;)

do góry

środa, 25 sierpnia 2021 o 10:35:46 UTC+2 Mateusz Viste napisał(a):
> 2021-08-25 o 10:02 +0200, heby napisał:
> > On 25/08/2021 09:53, Mateusz Viste wrote:
> > >> On 24/08/2021 17:50, Maciek Godek wrote:
> > >>> Pamiętam, że kiedyś robiłem brancha na SVNie i to był koszmar.
> > >> U mnie trwa około 2 sekund.
> > > Bo tu oczywiście nie chodziło o branch, tylko o merge. :)
> >
> > Super. Coś koło 4-5 sekund.
> Dzisiaj, tak. Dlatego pisałem, że to żaden koszmar, choć jeśli kolega
> Maciek eksperymentował z svn w latach 200x, to mógł zaobserwować
> gorsze wyniki. Ale nie wiem czy faktycznie się na tym przejechał, czy
> po prostu tak przeczytał na jakimś forum i pomyślał że to fajny
> argument - wszak taki mechanizm jest mi również znany.

Ostatni raz korzystałem z SVN w okolicach 2012 roku, i wspominam robienie branchy i
merge'ów jako koszmar.

W gicie sporo innych rzeczy wspominam jako koszmar, ale bym powiedział, że tak jak
SVN jest porządniej zaimplementowany i ma lepsze interfejsy, git jest lepiej
koncepcyjnie pomyślany i bardziej skalowalny, ale implementacja i projekt interfejsu
są raczej do bani.

No i git rzeczywiście jest bardziej modny, co mimo wszystko ma jakieś tam znaczenie -
np. jeżeli idzie o dostępność hostingu.

Tak czy siak - jak Sobczak słusznie zauważył - dywagowanie o wyższości jednego
systemu kontroli wersji nad drugim w wątku dotyczącym problemów w programie C++owym
nie ma za dużo sensu.

Śledzenie zmian w takim czy innym VCSie jest elementem higieny pracy programisty i
może niekiedy pomóc wyłapać błędy, które się wprowadziło na jakimś etapie rozwoju
projektu.

Ja bym każdemu kto jeszcze nie ma swojej preferencji raczej polecał gita, i to
właśnie ze względu na ową "modność"

Swego czasu korzystałem z mercuriala z hostingiem na bitbuckecie, ale atlassian
uznał, że nie będzie już wspierał mercurialowych repozytoriów, i zamiast je
przekonwertować do gita (na co bez trudu można znaleźć gotowe skrypty), to mi je
skasował (!)

do góry

2021-08-25 o 11:03 +0200, heby napisał:
> Przykład:
>
> 1) robie brancha z trunka
> 2) na trunku ktoś usuwa plik A i dodaje krytyczny ficzer
> 3) zaciągam do branch zmianę z 2)
> 4) ktoś rewertuje omyłkowo usunięty plik na trunku
> 5) ja merguje się z moim branchem do trunka
> 6) plik A znika

Ach takie jaja. No to tego po prostu nie robimy. Jeśli ktoś robi
branch, to pracuje na nim w izolacji aż do zespawania (lub porzucenia,
bo to często dla potrzeb jakiegoś prototypowania). A jak mu się nie
podoba, to niech branchuje na nowo. Czyli w efekcie wychodzi na to
samo, co opisujesz. Wydaje mi się, że tak jest zdrowiej, no i przede
wszystkim łatwiej się później człowiekowi (mi) połapać kto co dodał,
dlaczego i w którym momencie.

Mateusz

do góry

On 25/08/2021 11:20, Maciek Godek wrote:
> Ostatni raz korzystałem z SVN w okolicach 2012 roku, i wspominam robienie branchy i
merge'ów jako koszmar.

Korzystam z jednego i tego samego repo od ~2005 roku, od rewizji 0.
Nigdy nie nazwałbym tego koszmarem. Szczególnie od czasu pojawienia się
lokalnych dysków ssd, które problemy zredukowały do sekund.

> Tak czy siak - jak Sobczak słusznie zauważył - dywagowanie o wyższości jednego
systemu kontroli wersji nad drugim w wątku dotyczącym problemów w programie C++owym
nie ma za dużo sensu.

Sens ma w wyższej skali. Zachowania związane z VCS mają wpływ na flow pracy.

Chciałbym np., aby ciągła intergracja ciągle puszczała mi unit testy, po
każdym commicie w *branch*.

Gitowiec się oburzy, bo przeciez to jego przejaświętszy branch, gdzie
poza kodem trzyma też zdjecia kotów, liste zakupów w spożywczaku i kilka
*.mp4 z przyrodniczymi, a ponadto on ma 7 poprawek na tym "branchu", bo
co będzie tracił czas na 7 branchów.

Innymi słowy: C++ może i wsio rawno, ale w przypadku wyższej warstwy,
wpływ jest widoczny, na styl pracy.

do góry

2021-08-25 o 02:20 -0700, Maciek Godek napisał:
> Ostatni raz korzystałem z SVN w okolicach 2012 roku, i wspominam
> robienie branchy i merge'ów jako koszmar.

Na świeżej (wówczas) wersji svn? Dziwne. Musiałbyś więcej szczegółów
podać, albo powtórzyć doświadczenie i opisać.

> git jest lepiej koncepcyjnie pomyślany

Do bani z taką koncepcją, że każdy musi mieć na pececie swój własny
"niby-serwer" i synchronizować wszystko w obie strony, przy tym
chowając swoja zmiany przed światem tak długo, jak się da. No i te
setki opcji, przełączników, trybów...

> i bardziej skalowalny

Nie będę się spierał, bo moje doświadczenie w adminowaniu svn-em jest
ograniczone do kilkuosobowych projektów, ale niemniej wypadałoby to
stwierdzenie jakoś uargumentować. Przez wiele lat z svn korzystały duże
i bardzo duże projekty. Wnioskuję więc, że jednak da się. Jednym z
ostatnich "dużych" projektów open-source, który wyemigrował z svn jest
FreeBSD. Jeden z core programistów podaje przesłanki za tą zmianą:
https://bsdimp.blogspot.com/2020/09/freebsd-subversi
on-to-git-migration.html

W żadnym punkcie nie pada "gorsza skalowalność". Podane argumenty
sprowadzają się do dwóch rzeczy: "bo wszyscy tak robią" i "git pozwala
ładnie formatować patche, ułatwiając ich przyjmowanie z zewnątrz".

> Tak czy siak - jak Sobczak słusznie zauważył - dywagowanie o
> wyższości jednego systemu kontroli wersji nad drugim w wątku
> dotyczącym problemów w programie C++owym nie ma za dużo sensu.

Dyskusja to taki proces, że z czasem może zupełnie zmienić kierunek, w
zależności od zainteresowań i woli jej uczestników.

> Ja bym każdemu kto jeszcze nie ma swojej preferencji raczej polecał
> gita, i to właśnie ze względu na ową "modność"

Czyli już nie ze względu na "dług technologiczny", "niebotyczne
komplikacje" i rzekomą "prostotę gita"? No ok, moda to też jakiś
argument. Niekoniecznie zresztą zły.

Mateusz

do góry

środa, 25 sierpnia 2021 o 11:55:26 UTC+2 Mateusz Viste napisał(a):
> 2021-08-25 o 02:20 -0700, Maciek Godek napisał:
> > Ostatni raz korzystałem z SVN w okolicach 2012 roku, i wspominam
> > robienie branchy i merge'ów jako koszmar.
> Na świeżej (wówczas) wersji svn?

Nie wiem. Pewne dość świeżej bo to stało na w miarę aktualnym Ubuntu.

> Dziwne. Musiałbyś więcej szczegółów podać, albo powtórzyć doświadczenie i opisać.

Pewnie tak, ale na to raczej nie ma szans :D

> > git jest lepiej koncepcyjnie pomyślany
> Do bani z taką koncepcją, że każdy musi mieć na pececie swój własny
> "niby-serwer" i synchronizować wszystko w obie strony, przy tym
> chowając swoja zmiany przed światem tak długo, jak się da. No i te
> setki opcji, przełączników, trybów...

Główna koncepcja to jest raczej "content-addressable storage".

Od strony doświadczenia użytkownika można z tego korzystać dokładnie tak samo, jak z
SVNa, jeśli się chce.

Co do "chowania wszystkiego przed światem tak długo, jak się da", to nie rozumiem.

> > i bardziej skalowalny
>
> Nie będę się spierał, bo moje doświadczenie w adminowaniu svn-em jest
> ograniczone do kilkuosobowych projektów, ale niemniej wypadałoby to
> stwierdzenie jakoś uargumentować. Przez wiele lat z svn korzystały duże
> i bardzo duże projekty. Wnioskuję więc, że jednak da się. Jednym z
> ostatnich "dużych" projektów open-source, który wyemigrował z svn jest
> FreeBSD. Jeden z core programistów podaje przesłanki za tą zmianą:
> https://bsdimp.blogspot.com/2020/09/freebsd-subversi
on-to-git-migration.html
>
> W żadnym punkcie nie pada "gorsza skalowalność".

Tutaj jest:
"Git can easily and robustly be mirrored. Subversion can be mirrored, but that
mirroring is far from robust."

do góry

wtorek, 24 sierpnia 2021 o 10:12:13 UTC+2 Maciek Godek napisał(a):
> Zacząłbym od tego, że w momencie zapisywania pliku cache.xml tworzyłbym również
plik z logami (może być nawet zapis na stderr, który byłby zrzucany do jakiegoś
pliku) i wówczas, jeżeli bym zobaczył, że plik jest zepsuty, to bym sobie dogłębnie
te logi przeanalizował.

Zrobiłem makro TRACE(...) ale problem jest w tym, że nie udaje mi się odtworzyć
błędnego przypadku, występuje zbyt rzadko i nie wiem od czego zależy.

do góry

Pomyślełem, że skoro problem strs="" występuje tak rzadko to mogę nic nie zapisywać
do cache.xml gdy wyliczone strs="". Program raz na jakiś czas będzie działał wolniej,
ale będzie nadal produkował poprawne wyniki, więc nie jest to jakaś poważna wada.
Chyba tak zrobię.

do góry