Boszz... a miał być EOT.

On 2010-10-05 19:58, Bodek wrote:
> Jakbyś zamiast podniecania się SVN-em poużywał trochę gita, to byś
> wiedział, że operacje typu log, commit, zmiana brancha są w nim
> _natychmiastowe_. SVN z jego oczekiwaniem w nieskończoność na
> zakończenie byle pierdółki (nawet po LAN-ie) jest po prostu śmieszny.

Ja byś kiedykolwiek używał SVNa to być wiedział, że operacje typu zmiana
brancha sa natychmiastowe. Przed chwilą mierzyłem u siebie po lanie.
Projekt około 2tys plików java, kilkanascie MB w sumie. Zrobienie nowego
brancha - poniżej sekundy. Switch ze zmianą 2 plików - około 3 sekund. Z
czego wszystko to jazda po dysku. Jesli mi teraz powiesz że git jest o
450ms szybszy to pozostaje mi popukać się w czoło.

Na dużym repozytorium (kilkaset MB) switch trwa max pare sekund i ma
zwiazek z iloscią katalogów a nie wielkością plików (o ile ich nie zmienia).

> Taki ma sens, że nie raz, nie dwa, a nawet nie sto razy się zdarzało,
> że w jednym pliku nagle znalazły się zmiany dotyczące kilku różnych
> rzeczy na raz.

Kiedyś pewien mój znajomy, zatwardziały gitowiec mial podobne objawy.
Jak mu pokazałem jak to robie w SVN to mu się tylko pogłębiły. Od tamtej
pory odnosze wrazenie, że ludzie uzywają gita (i nie tylko) mniej więcej
w taki sam sposób w jaki utrzymują porzadek przed monitorem. Czyli
burdel. Ale czerpie tą opinię z paru tylko przykładów, doceniam jednak
że dostarczyłeś mi nastepny do kolekcji.

Jesteś ekologiem ze żal Ci tych paru bitów na zrobienie osobnych
branchy? Naprawdę, one czarodziejsko nie powiększają repozytorium a lasy
tropikalne nie cierpią. Ktoś te branche wymyślił w jakimś celu. Może po
prostu przemyśl w jakim zamiast robić 10 bugow na jednym branchu a potem
mysleć ktora linijka jest do czego i szukając narzędzi które to ułatwiają.

> I trzeba to było jakoś zacommitować. Na SVN-ie albo
> zrobisz burdel commitując wszystko na raz (bardzo częsty i przykry
> widok), albo się będziesz dłubał przez pół dnia próbując zrobić
> dobrze.

Jesli masz burdel na branchu to trudno się dziwić że masz burdel w
commitach. Czy aby przypadkiem git nie ma narzędzi sworzonych dla
bałaganiarzy?

Mam prostą zasadę: jeden bug/feature - jeden branch. Jesli masz
zależoności to robisz po kolei. Sprawa prosta. A jaka wygodna. Że już o
testach regresyjnych nie wspomne. Ale gdzie mi się tam rownać z
profesjonalnym bisect ...

Od razu przyznaje że w SVN brakuje mi wygodnej mozliwości zrobienia
revert dla fragmentu pliku. Ale akurat to da się obejść zewnętrznymi
narzedziami, choć to upierdliwe.

> A jak się pomylisz, to kaplica, bo poszło na serwer i się już
> odkręcić tego nie da w żaden sposób.

O BOŻE! Już nie ma reverta? Czy to już po końcu świata?

> Patrz wyżej. Nie wyobrażam sobie (już), żeby zmiany szły na serwer od
> razu podczas commita.

Byc może to nastepny objaw bałaganiarstwa. "Wydaje mi się że ta poprawka
w 94.67% jest ok. A h... commituje, najwyżej jutro sprawdze
dokładniej.". Nie, tak się nie robi. Sorry że musialem Ci to uświadomić.
Albo robisz co chcesz na *branchu*, albo masz 100% pewności ze to co
komitujesz na *trunk* ma sens. Nie ma opcji w środku.

> Zdarza mi się czasem popełniać dosyć oczywiste
> błędy i bardzo sobie cenię możliwość skorygowania lokalnej historii
> repozytorium, tak żeby o moich pomyłkach nikt się nigdy nie
> dowiedział.

Wlasnie zaprzeczyłeś sensowi istnienia systemów kontroli wersji. Gratuluje.

> Co więcej, początkowe implementacje nowych rzeczy mają do
> siebie to, że są robione trochę na czuja. Często po jakimś czasie
> (godzina, pół dnia, dwa dni), w miarę zgłębiania problemu wiedza na
> jego temat poszerza się o tyle, że tą początkową implementację chciało
> by się zmienić.

I tu nagle odkrywasz branche i reverty. Gratuluje.

> Git daje mi taką możliwość, SVN nie.

Bo:

a) nie widzialeś SVN na oczy.

b) nie masz pojęcia jak sie sensownie pracuje (w obydwu systemach).

Jeśli potrzebujesz malego szkolenia to mogę pokazać. Wystarczy że dasz
znać. Mówie serio.

> To ile w repozytoriach które używasz robiłeś _prywatnych_ gałęzi kodu
> z _eksperymentalnymi_ rzeczami które nie wiesz czy zadziałają i w
> zasadzie wstyd jest je komuś pokazywać?

Setki razy. Tylko ze mi nie jest wstyd.

> W SVN-ie taka gałąź będzie
> widoczna do końca świata.

Ja się nie wstydzę. Co gorsza jak za pół roku wpadne jednak na to że to
nie było aż takie złe rozwiązanie to mam je schowane w miarę bezpiecznym
miejscu.

> Chciałbym zobaczyć w jaki sposób te kilka linijek w bashu radzi sobie
> z SVN-owymi merge'ami pozbawionymi historii.

A widzisz jakiś problem numeryczny z obliczeniem mediany dwoch liczb na
trunku? Pomijając fakt, że jak się nie ma burdelu to wykrywanie regresji
jest możliwe do zautomatyzowania po każdym commicie.

> Poza szybkością

Jak w SVN z dokładnoscią do ms na małych projektach.

> gotowością rozwiązania

Jak w SVN.

> automatyzacją

Jak w SVN.

> i możliwością
> poprawienia błędu u źródła

Jak w SVN.

, a nie w późniejszym commicie. Ale poza tym
> to zupełnie nic.

W gruncie rzeczy tak samo jak SVN.

Jestes następnym człowiekiem ktory nie widział na oczy SVN używanego
przez osobę świadomą i wyrabiasz sobie opinie na podstawie błednych
obserwacji. Może warto by pooglądać jak wygląda flow kodowania w SVN
gdzieś gdzie nie robią tego nastolatki w przerwach wyciskania pryszczy?