wtorek, 24 sierpnia 2021 o 10:57:42 UTC+2 r...@g...com napisał(a):
> wtorek, 24 sierpnia 2021 o 10:12:13 UTC+2 Maciek Godek napisał(a):
> > poniedziałek, 23 sierpnia 2021 o 20:57:59 UTC+2 r...@g...com
napisał(a):
> > > poniedziałek, 23 sierpnia 2021 o 16:48:49 UTC+2 Maciek Godek napisał(a):
> > > > poniedziałek, 23 sierpnia 2021 o 16:04:12 UTC+2 r...@g...com
napisał(a):
> > > > > poniedziałek, 23 sierpnia 2021 o 15:44:35 UTC+2 Maciek Godek napisał(a):
> > > >
> > > > > w pliku cache.xml mam atrybut strs="" a powinien być niepusty string
> > > > No dobra, to już jest coś.
> > > > A teraz kilka pytań bardziej konkretnych: w jaki sposób i w jakich
okolicznościach tworzysz plik cache.xml?
> > > Pod koniec działania programu. Wykorzystuję bibliotkę pugixml (i xml_document).
Mam z nią problemy, musiałem użyć atrybutu, bo zapisywanie w treści węzła nie
działało mi.
> > > > W jaki sposób atrybut "strs" jest reprezentowany w pamięci podczas działania
programu?
> > > vector<string>, robię strs = implode(magic_str, vector<string>)
> > Skąd jest ta funkcja "implode"?
> to moja funkcja a la PHP - łączy stringi z kolekcji przedzielone pierwszym
parametrem w jeden string

Tzn. się domyślam do czego służy.
Raczej bym chciał zobaczyć definicję, żeby stwierdzić, czy nie ma w niej jakiegoś
nieoczywistego błędu
(skoro to nie jest funkcja z biblioteki standardowej)

Ewentualnie możesz spróbować ją zamienić na biblioteczną, np. z boost:

https://stackoverflow.com/questions/5689003/how-to-i
mplode-a-vector-of-strings-into-a-string-the-elegant
-way

(tak czy siak, lepiej w miarę możliwości korzystać z gotowców, niż pisać własne
funkcje na rzeczy, dla których gotowce istnieją)

> > > moje vector<string> to drugie składowe unordered_map<wstring, vector<string>>
> > 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ł.
> > > > Używasz systemu kontroli wersji (np. git) do rozwijania programu?
> > > nie
> > To zacznij. Najlepiej już dziś.
> na razie czytam książkę o git-cie

W najprostszym razie piszesz po prostu "git init" w folderze, który chcesz
wersjonować, i później "git commit zmodyfikowane_pliki..." po każdej istotnej
zmianie.

Ale najlepiej założyć sobie konto na jakimś serwisie w rodzaju githuba albo gitlaba i
tam trzymać cały kod (wtedy dochodzą jeszcze operacje "git push" i "git pull", żeby
synchronizować ze sobą repozytoria)

To jest o tyle spoko, że te serwisy od razu udostępniają narzędzia do wygodnego
przeglądania zmian.

do góry

wtorek, 24 sierpnia 2021 o 11:19:51 UTC+2 Mateusz Viste napisał(a):
> 2021-08-24 o 01:57 -0700, Robert Magdziarz napisał:
> > na razie czytam książkę o git-cie
> Sztuka dla sztuki. Więcej czasu spędzisz na głowieniu się co
> wklepać żeby zadowolić gita niż na pisaniu kodu. Proponuję
> zainteresować się klasycznym svn-em, w codziennym użyciu ogarniesz go
> czterema poleceniami:
>
> svn up (zaciągnij najświeższy kod projektu)
> svn diff (porównaj mój lokalny kod z ostatnim commitem)
> svn st (zobacz które pliki lokalne są inne od tych w repo)
> svn commit (zapisz moje zmiany)
>
> Nie mówię przy tym, że git jest zły - jest po prostu bardziej
> skomplikowany, zarówno w swojej koncepcji jak i użytkowaniu. Pozwala
> też na więcej, ale w moim doświadczeniu to "więcej" jest zupełnie
> nieprzydatne i tylko wprowadza zamieszanie, przynajmniej przy
> kilkuosobowych projektach.

svn już raczej odchodzi do lamusa.
podstawowy workflow gita nie jest bardziej skomplikowany.

w jednoosobowym projekcie to zupełnie bez znaczenia, natomiast jeżeli projekt się
rozrasta, svn staje się długiem technicznym, bo operacje scalania ze sobą zmian od
różnych osób stają się niebotycznie skomplikowane.

serio.

nawet humaniści korzystają z gita przy kolaboracyjnym pisaniu książek.
przy svnie taka współpraca byłaby mocno utrudniona.

do góry

2021-08-24 o 07:39 -0700, Maciek Godek napisał:
> svn już raczej odchodzi do lamusa.

Efekt mody.

> w jednoosobowym projekcie to zupełnie bez znaczenia, natomiast jeżeli
> projekt się rozrasta, svn staje się długiem technicznym, bo operacje
> scalania ze sobą zmian od różnych osób stają się niebotycznie
> skomplikowane.
>
> serio.

Uwierzyłbym, gdybym nie używał svn-a od ponad 15 lat - również
zespołowo. Tych niebotycznych komplikacji, o których piszesz, nie
doświadczyłem. Widziałem natomiast rozterki programistów dumających nad
tym, jak ugryźć gita żeby się nie obraził - i spędzających godziny na
doktoryzowaniu się i dyskutowaniu w nieskończoność o tym, jak coś
zrobić... zamiast zająć się pożyteczną pracą.

Niewątpliwie istnieją sytuacje, w których git wykazuje zalety względem
svn - jakiś intensywny branching, możliwość pracy offline przy
lokalnym commitowaniu, itp. Ja takich potrzeb w praktyce nie zaznałem.
Dlatego uważam, ze w wielu przypadkach git jest zwyczajnie
przekombinowany. Lubię proste i skuteczne narzędzia - a svn taki
właśnie jest.

> nawet humaniści korzystają z gita przy kolaboracyjnym pisaniu książek.
> przy svnie taka współpraca byłaby mocno utrudniona.

W jaki sposób korzystają, i w jaki sposób utrudniona? W moich zespołach
zawsze trzymaliśmy wszelkie podręczniki i dokumentacje w svn, w postaci
plików tex lub html na podstawie których następnie coś budowało
wynikowego PDFa. I tutaj nie przypominam sobie by svn cokolwiek
utrudniał.

Mateusz

do góry

wtorek, 24 sierpnia 2021 o 17:27:16 UTC+2 Mateusz Viste napisał(a):
> 2021-08-24 o 07:39 -0700, Maciek Godek napisał:
> > svn już raczej odchodzi do lamusa.
> Efekt mody.

W jakiejś mierze pewnie tak. Na pewno z mercurialem git "wygrał" ze względu na modę.

> > w jednoosobowym projekcie to zupełnie bez znaczenia, natomiast jeżeli
> > projekt się rozrasta, svn staje się długiem technicznym, bo operacje
> > scalania ze sobą zmian od różnych osób stają się niebotycznie
> > skomplikowane.
> >
> > serio.
> Uwierzyłbym, gdybym nie używał svn-a od ponad 15 lat - również
> zespołowo. Tych niebotycznych komplikacji, o których piszesz, nie
> doświadczyłem. Widziałem natomiast rozterki programistów dumających nad
> tym, jak ugryźć gita żeby się nie obraził - i spędzających godziny na
> doktoryzowaniu się i dyskutowaniu w nieskończoność o tym, jak coś
> zrobić... zamiast zająć się pożyteczną pracą.
>

Pamiętam, że kiedyś robiłem brancha na SVNie i to był koszmar.

> Niewątpliwie istnieją sytuacje, w których git wykazuje zalety względem
> svn - jakiś intensywny branching, możliwość pracy offline przy
> lokalnym commitowaniu, itp.

Dokładnie. Sam pomysł, że musisz mieć centralne repozytorium, jest sporym
utrudnieniem.
Dlatego np. github ma guzik, którym możesz łatwo zforkować repozytorium i później
wysyłać pull-requesty do oryginalnego repozytorium; albo nie wysyłać.

Ja takich potrzeb w praktyce nie zaznałem.
> Dlatego uważam, ze w wielu przypadkach git jest zwyczajnie
> przekombinowany. Lubię proste i skuteczne narzędzia - a svn taki
> właśnie jest.

Właściwie to jest na odwrót.
Git jest dużo prostszym narzędziem. Już sam fakt, że wystarczy wpisać "git init",
żeby mieć u siebie repozytorium, o tym świadczy.
Dla SVNa musisz postawić serwer.

> > nawet humaniści korzystają z gita przy kolaboracyjnym pisaniu książek.
> > przy svnie taka współpraca byłaby mocno utrudniona.
> W jaki sposób korzystają, i w jaki sposób utrudniona?

Na przykład w taki:

https://github.com/OpenLogicProject/OpenLogic

A utrudniona, bo przy zbiorowej kolaboracji synchronizacja repozytoriów a'la SVN
byłaby koszmarem.
Na przykład github jądra Linuxa wyświetla 5000 współautorów.

> W moich zespołach
> zawsze trzymaliśmy wszelkie podręczniki i dokumentacje w svn, w postaci
> plików tex lub html na podstawie których następnie coś budowało
> wynikowego PDFa. I tutaj nie przypominam sobie by svn cokolwiek
> utrudniał.

A ile osób te zespoły liczyły?

do góry

2021-08-24 o 08:50 -0700, Maciek Godek napisał:
> Pamiętam, że kiedyś robiłem brancha na SVNie i to był koszmar.

Branch to nic innego, jak kopiowania - trwa szybko. Powolny natomiast
bywa zaiste merge, dużo zależy od rozmiarów kodu i ilości różnic w
sklejanych wersjach, przy czym w ostatnich latach svn zrobił na tym
polu duże postępy.

> Dokładnie. Sam pomysł, że musisz mieć centralne repozytorium, jest
> sporym utrudnieniem.

Mi to się właśnie bardzo podoba i raczej postrzegam tę całą
"decentralizację" gita jako utrudnienie. Ktoś naćka milion zmian w git
przez noc, to rano muszę wszystko kolejno zaciągać (i nie daj losie by
były tam jakieś większe pliki binarne). Przy svn zaciągam tylko
najświeższą, ostatnią wersję.

> Dlatego np. github ma guzik, którym możesz łatwo
> zforkować repozytorium i później wysyłać pull-requesty do
> oryginalnego repozytorium; albo nie wysyłać.

Guzik w interfejsie webowym to dla mnie żaden argument. Taki sam guzik
mógłby przecież być przy svn - robiłby "svn import", a ew. pull
requesty byłyby niczym innym jak przesłaniem patcha wyciągniętego z svn
diff.

> Git jest dużo prostszym narzędziem. Już sam fakt, że wystarczy wpisać
> "git init", żeby mieć u siebie repozytorium, o tym świadczy. Dla SVNa
> musisz postawić serwer.

Z założenia chodziło o kolaborację, w tym kontekście serwer wydaje się
dość rozsądnym rozwiązaniem. Ale jeśli nie chcesz to nie musisz - svn
równie dobrze może przecież pracować na lokalnym katalogu.

> A utrudniona, bo przy zbiorowej kolaboracji synchronizacja
> repozytoriów a'la SVN byłaby koszmarem. Na przykład github jądra
> Linuxa wyświetla 5000 współautorów.

Tak, to jest jeden z racjonalnych use-casów gita. Zresztą git powstał
właśnie do tego by usprawnić prace nad kernelem. Projekt, który ma 5000
współautorów to jednak nie jest norma i może wymagać specjalistycznego
podejścia. Równie dobrze (uwaga, samochodowa analogia! proszę o
tolerancję) mógłbym stwierdzić, że zamiast Tico kupię sobie ciągnik
siodłowy, bo przecież kiedyś lodówka może mi się rozrosnąć i będę
potrzebował zwieźć z warzywniaka 8 ton marchwi.

> A ile osób te zespoły liczyły?

Podawałem (chyba) wcześniej - od kilku do maks kilkunastu. Jeśli mowa o
projektach z tysiącem programistów stukających 24/24, to spierać się
nie będę - bo nie znam, i moja wypowiedź ich nie dotyczy.

Mateusz

do góry

> Lubię proste i skuteczne narzędzia

Przy pracy jednoosobowej takimi narzędziami są zip oraz unzip. Polecam.
Zwłaszcza, że oprócz historii zmian potrafią zupełnie naturalnie zrobić backup - a to
jest *ważniejsze*, niż zabawa w commity.
Nie, lokalny git to nie jest backup.

Jednoosobowy lokalny git ma wartość co najwyżej hobbystyczną albo edukacyjną ("Czy ma
Pan doświadczenie z gitem? Tak, od 5 lat."), ale jego użytkowa wartość dodana wynosi
epsilon.
To jest bardzo wymowne, że zamiast poprawiać błędy w programie dyskusja jest o
wyższości gita nad svnem. :-D

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

do góry

On 23/08/2021 20:51, Maciej Sobczak wrote:
> valgrind [...]

W tym przypadku koniecznie --track-origins=yes

do góry

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. 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
brancha. Może faktycznie niewielkie to repo w porównaniu z typowym
helloworldem z githuba.

Ilośc danych jakie latają po sieci przy tej operacji jest mniejsza niż
przy szukaniu obrazków z kotami po googlu.

>> Niewątpliwie istnieją sytuacje, w których git wykazuje zalety względem
>> svn - jakiś intensywny branching, możliwość pracy offline przy
>> lokalnym commitowaniu, itp.
> Dokładnie. Sam pomysł, że musisz mieć centralne repozytorium, jest sporym
utrudnieniem.

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.

> Właściwie to jest na odwrót.
> Git jest dużo prostszym narzędziem. Już sam fakt, że wystarczy wpisać "git init",
żeby mieć u siebie repozytorium, o tym świadczy.

Nie, to tylko świadczy o tym, że jest nastawiony na inne zagadnienia niż
praca zespołowa. Niektórzy uważają GITa za narzędzie dla schizofreników
i spiskowców. Właśnie z tego powodu, jak nastawienie na pracę offline. W
pracy zespołowej to kuriozum, że chowasz swoje wypociny przed innymi. A
jak ktoś będzie musiał ją przejąć, bo umrzesz? A jak będziesz chciał
ciągłą integrację na swoim branchu na centralnej farmie kompilującej? A
jak kolega będzie chciał Ci pomóc? Zaleta? Serio? Gdzie?

> Dla SVNa musisz postawić serwer.

Brednia. Możesz stworzyć bazę danych SVN w *katalogu* na dysku lokalnym.
JEDNO kliknięcie, w TortoiseSVN. Tylko nikt tak nie robi podczas pracy.
To głupie.

> A utrudniona, bo przy zbiorowej kolaboracji synchronizacja repozytoriów a'la SVN
byłaby koszmarem.

Dlatego każdy używający SVN nie jest do tego stopnia idiotą, aby mieć
osobne, prywatne repozytoria. Ludzie miewają szybki internet. Szybszy
niż w latach 90. Centralne repo nie jest niczym dziwnym. Ba, działa
absurdalnie szybko, przy tym moim, skromnym repo.

> Na przykład github jądra Linuxa wyświetla 5000 współautorów.

I to oznacza że masz 5000 lokalnych repozytoriów? Czyli, mówiąc
prościej, rozrzuciłeś problemy synchronizacji na 5000 osób i wszyscy
udają że już go nie ma?

Na svn by go *naprawdę* nie było. Tak najzwyczajniej, w SVN nie ma
problemu z synchronizacją. O ile potrafisz go używać.

> A ile osób te zespoły liczyły?

Ilość userów nijak nie zwiększa problemów pracy SVN. Rozmiar repo też.

Powtarzasz jakieś zasłyszane i niezweryfikowane brednie. Swoją droga
powtarzają je wszyscy gitowcy jacy przewineli się przez moje ręce, po
bliższej analizie okazuje się że nie mieli pojęcia jak sie obsługuje
SVN, robili to źle i marudzili, że nie działa lub wyczytali multum
podobnych bredni z internetach.

Nikt nie twierdzi, że git jest lepszy/gorszy, bo to narzedzie do innych
zastosowań niż centralne repo na szybkich łaczach internetowych. Czyli
90% potrzeb i możliwości przeciętnej firmy w PL.

Nie jestem zwolennikiem SVN, ale szlag mnie trafia kiedy słyszę takie
brednie. SVN to zaskakująco stabilny i zacny kawał softu. To że jest
chwilowa moda na gita o niczym nie świadczy. Na pewno nie o tym, że ma
jakieś znaczące zalety w typowym flow w typowej firmie z centralnym
repo. Jak narazie, typowi gitowiec pytany o prawdziwe zalety git vs svn
zazwyczaj nie ma ani jednej która by nie wynikała z błednego uzycia svn.
I mam wrażenie że nie bez powodu: nie ma tak naprawdę argumentów. To
tylko moda i propaganda.

Czekam na coś lepszego. Już ze 20 lat.

do góry

2021-08-24 o 11:58 -0700, Maciej Sobczak napisał:
> > Lubię proste i skuteczne narzędzia
>
> Przy pracy jednoosobowej takimi narzędziami są zip oraz unzip.

Wyczuwam bratnią duszę. Doceniam.

> Polecam. Zwłaszcza, że oprócz historii zmian potrafią zupełnie
> naturalnie zrobić backup - a to jest *ważniejsze*, niż zabawa w
> commity. Nie, lokalny git to nie jest backup.

Z tym jednak zgodzić się nie mogę... Lokalny VCS to oczywiście nie
backup, ale lokalny zestaw plików *.zip też nim nie jest. W obu
przypadkach wypadałoby zrzucić pliki gdzieś na zewnątrz. svn akurat
ma to w standardzie (git też, chyba że ktoś upiera się korzystać z tych
jego "lokalnych" funkcji).

> Jednoosobowy lokalny git ma wartość co najwyżej hobbystyczną albo
> edukacyjną ("Czy ma Pan doświadczenie z gitem? Tak, od 5 lat."), ale
> jego użytkowa wartość dodana wynosi epsilon.

Bez przesady. Lokalny git, svn czy inny rcs to narzędzia które mają
sens nawet lokalny. I oczywiście można zadowolić się zipem, zip-diffem
itd, ale kosztem pewnej wygody użytkowania. Zamiast robić zipa i
kopiować go gdzieś na jakiś serwer po FTP, rsync itp, robię zwyczajne
svn commit i mam pewność, że moje zmiany już się nie zgubią.
Korzystanie z ZIP to również marnotrawstwo miejsca - ten sam plik
będzie w każdym zipie zajmował tyle samo miejsca, choć od wielu lat nie
uległ zmianie. Jest jeszcze jeden aspekt: często zdarza się, że
potrzebuję prześledzić historię jednego pliku (spośród kilkunastu
tysięcy w projekcie) na przestrzeni paru lat. Ciężko mi wyobrazić to
sobie przy milionach plików ZIP.

Mateusz

do góry

2021-08-24 o 21:40 +0200, heby napisał:
> 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. :)
Te bywają długawe - ale w żadnym wypadku nie określiłbym ich dziś jako
"koszmar". We wczesnych wersjach subversion ten proces faktycznie był
mało optymalny, ale mówię tu o pierwszej dekadzie wieku - od tego czasu
subversion znacząco się pod tym kątem poprawiło.

> 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".

> 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. A
nawet wręcz przeciwnie, bo każdy z eskimosów będzie musiał
synchronizować u siebie wszystkie możliwe wersje kolegów. svn jest tu
daleko oszczędniejszy.

Jakimś racjonalnym use casem dla git byłaby praca na Saturnie.
Saturnianie pracują sobie spokojnie u siebie, a kiedy raz na jakiś czas
otwiera się okienko komunikacji z ziemią, to przesyłają wszystko jednym
rzutem do centrali (licząc, że koledzy z ziemi nie narobili w
międzyczasie jakichś kolizji).

> Dlatego każdy używający SVN nie jest do tego stopnia idiotą, aby mieć
> osobne, prywatne repozytoria. Ludzie miewają szybki internet. Szybszy
> niż w latach 90.

Tu nawet nie potrzeba szybkiego internetu. Przez kilka lat pracowałem
na łączu 64 Kbps, przesłanie kilku kilobajtów w ramach commita nie było
żadnym problemem. Dłużej trwało odebranie emaila.

> 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...

> > A ile osób te zespoły liczyły?
>
> 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).
Ale fakt - to już temat poza gestią VCS-a. No i git tak czy inaczej
w żaden sposób tu niczego nie ułatwia, a raczej wręcz utrudnia.

> Nie jestem zwolennikiem SVN

Z ciekawości - dlaczego? W sensie - jakie widzisz w nim mankamenty? Bo
mi naprawdę trudno się do czegokolwiek przyczepić.

Mateusz

do góry