2021-08-25 o 03:09 -0700, Maciek Godek napisał:
> Główna koncepcja to jest raczej "content-addressable storage".

Nie ma w tym niczego fajnego, to tylko pokłosie decentralizacji.

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

Znaczy patrząc na dwie rewizje mogę rzutem oka stwierdzić, która jest
wcześniejsza, i oszacować mniej więcej o ile? No to git. :)

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

O lokalne commity chodzi, i o kryjące się za nimi podejście "nie
pokażę co robię póki nie wycackam tego do końca".

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

Klonowanie repozytoriów svn działa bardzo sprawnie (svnsync),
korzystałem z tego wielokrotnie w ramach przeprowadzania repozytoriów
svn między serwerami, a także w ramach duplikowania lokalnego repo
FreeBSD w domu, kiedy jeszcze miałem w piwnicy kilka instalacji BSD.
Ale fakt - nie jest to "wbudowane w protokół" i może wymagać nieco
rzeźby przy jakichś egzotyczniejszych wymaganiach.

Mateusz

do góry

środa, 25 sierpnia 2021 o 14:44:04 UTC+2 Mateusz Viste napisał(a):


> > Od strony doświadczenia użytkownika można z tego korzystać dokładnie
> > tak samo, jak z SVNa, jeśli się chce.
> Znaczy patrząc na dwie rewizje mogę rzutem oka stwierdzić, która jest
> wcześniejsza, i oszacować mniej więcej o ile? No to git. :)

Oczywiście. Git loguje datę każdego commita. Nie wiem, dlaczego to by miało
zaskakiwać.

> > Co do "chowania wszystkiego przed światem tak długo, jak się da", to
> > nie rozumiem.
> O lokalne commity chodzi, i o kryjące się za nimi podejście "nie
> pokażę co robię póki nie wycackam tego do końca".

Nie bardzo rozumiem jaką lepszą alternatywę daje SVN.
"Nie scommituję dopóki nie wycykam tego do końca"?

do góry

On 25/08/2021 15:39, Maciek Godek wrote:
> Nie bardzo rozumiem jaką lepszą alternatywę daje SVN.
> "Nie scommituję dopóki nie wycykam tego do końca"?

Takie sytuacje to patlogia w grupach używających SVN. Codziennością są
natomiast dziesiętki commitów dzienie w *jawny* branch.

do góry

2021-08-25 o 16:18 +0200, heby napisał:
> On 25/08/2021 15:39, Maciek Godek wrote:
> > Nie bardzo rozumiem jaką lepszą alternatywę daje SVN.
> > "Nie scommituję dopóki nie wycykam tego do końca"?
>
> Takie sytuacje to patlogia w grupach używających SVN. Codziennością
> są natomiast dziesiętki commitów dzienie w *jawny* branch.

Całkiem inne podejście, tak.

Wpadłem właśnie na ciekawy (acz stary) post. Napisany starannie i z
humorem. Podaję linka do lektury przy kawie, gdyby ktoś nie znał. :)

https://www.bitquabit.com/post/unorthodocs-abandon-y
our-dvcs-and-return-to-sanity/

Mateusz

do góry

wtorek, 24 sierpnia 2021 o 16:33:53 UTC+2 Maciek Godek napisał(a):
> > > 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)

string implode(const string delim, const vector<string> &v) {
string s = "";
for (auto iter = v.begin(); iter != v.end(); ++iter) {
s += (*iter);
if (iter + 1 != v.end()) {
s += delim;
}
}
return s;
}

do góry

środa, 25 sierpnia 2021 o 18:14:40 UTC+2 Robert Magdziarz napisał(a):
> wtorek, 24 sierpnia 2021 o 16:33:53 UTC+2 Maciek Godek napisał(a):
> > > > 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)
> string implode(const string delim, const vector<string> &v) {
> string s = "";
> for (auto iter = v.begin(); iter != v.end(); ++iter) {
> s += (*iter);
> if (iter + 1 != v.end()) {
> s += delim;
> }
> }
> return s;
> }

Jak dla mnie to wygląda całkiem prawilnie (choć z C++em to nigdy do końca nie
wiadomo).
Rozumiem że "string" to std::string i "vector" to std::vector?

W każdym razie raczej wygląda na to, że string jest pusty, bo tablica z jakichś
względów jest pusta.

Jesteś w stanie określić wszystkie operacje, których dokonujesz na tej tablicy?

do góry

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

Lokalny nie jest. Ale nie napisałem, że lokalny. Nawet pendrive załatwi sprawę
łatwiej, niż szarpanie się z VCS. Bo oczywiście nie używamy cały czas tylko jednego
pendrive'a. A może jednak Google Drive? Albo Box? A właściwie bez różnicy, bo zip w
ogóle nie jest od tego uzależniony. Jest narzędziem tak łatwym w użyciu, że cokolwiek
innego jest zawsze dodatkową komplikacją. Dotarło to do mnie, gdy pierwszy raz w
życiu zzipowałem lokalne repo gita, żeby zrobić jego backup. Absurdalność tej
czynności sprawiła, że to był też ostatni dzień mojego jednoosobowego użytkowania
gita.

> W obu
> przypadkach wypadałoby zrzucić pliki gdzieś na zewnątrz. svn akurat
> ma to w standardzie

Zdażyło mi się nawet wysłać zipa jako załącznik mailem. Nie, svn nie ma tego w
standardzie. Właśnie o to chodzi - o *rozdzielenie* kompetencji. Zamrożenie stanu
plików w katalogu to jedna rzecz (potrzebne do historii), składowanie tego stanu to
inna rzecz (potrzebne do backupu). Zip jest banalnie skuteczny właśnie przez to, że
tych rzeczy nie łączy.

> Zamiast robić zipa i
> kopiować go gdzieś na jakiś serwer

A jeśli nie chcę na "jakiś serwer"? Czemu wszyscy mają obsesję na punkcie wysyłania
swojej pracy na "jakiś serwer"?
Kiedyś do komputera był podłączony magnetofon i był spokój. :-)

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

Technicznie to prawda, ale użytkowo nigdy jeszcze nie doszedłem do tego, żeby martwić
się o miejsce na skompresowane pliki źródłowe swojego autorstwa. Może za mało piszę.
W każdym razie nie jest to showstopper.

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

To jest dobry argument. Ale mówimy o użytkowaniu jednoosobowym. W takim kontekście
nie zaobserwowałem (u siebie) takich potrzeb. Nawet wtedy, gdy korzystając
jednoosobowo z gita, miałem taką możliwość na wyciągnięcie palca. Czyli podobnie jak
z brakującym miejscem na dysku, nie jest to scenariusz, który mnie zatrzymuje w
pracy.
Polecam narzędzi mniej, niż więcej.

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

do góry

W dniu 24.08.2021 o 20:58, Maciej Sobczak pisze:
>> 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.
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ć.

do góry

środa, 25 sierpnia 2021 o 21:22:57 UTC+2 Maciek Godek napisał(a):
> Rozumiem że "string" to std::string i "vector" to std::vector?

tak

>
> W każdym razie raczej wygląda na to, że string jest pusty, bo tablica z jakichś
względów jest pusta.

tak

>
> Jesteś w stanie określić wszystkie operacje, których dokonujesz na tej tablicy?

algorytm wstawiający stringi do vectora jest skomplikowany (liczy setki linii) i
prawdopodobnie zawiera błąd logiczny, ale nie wiem jak ten błąd znaleźć

do góry

czwartek, 26 sierpnia 2021 o 06:57:57 UTC+2 Robert Magdziarz napisał(a):

> > Jesteś w stanie określić wszystkie operacje, których dokonujesz na tej tablicy?
> algorytm wstawiający stringi do vectora jest skomplikowany (liczy setki linii) i
prawdopodobnie zawiera błąd logiczny, ale nie wiem jak ten błąd znaleźć

Jedną z metod jest pisanie przypadków testowych. Jeżeli jesteś w stanie wyodrębnić
ten algorytm do osobnego programu, i uruchamiać z różnymi danymi wejściowymi, to to
już jest duże ułatwienie.

Wówczas jednym z pomysłów, oprócz ręcznego napisania przypadków testowych, byłoby też
napisanie generatora losowych danych wejściowych, które powinny spełniać założenia
algorytmu.

Stąd kolejne pytanie: czy ten "algorytm" jest w miarę scentralizowany (tzn. jest
jedna funkcja/procedura, która zajmuje się wstawianiem danych do tablicy), czy może
rozproszony po całym programie?

W tym pierwszym przypadku byłoby oczywiście łatwiej, ale jeżeli tak nie jest, to
trzeba by zakasać rękawy i wyszukać wszystkie miejsca w programie, które modyfikują
tę tablicę.

Inna alternatywa byłaby taka, żeby ten algorytm napisać od podstaw, w sposób bardziej
zdyscyplinowany.

do góry