On 4 Paź, 23:31, Sebastian Biały <h...@p...onet.pl> wrote:
> > - Git jest znacznie szybszy niż SVN (nawet działający po sieci lokalnej)
> >    - wycheckoutowanie kilku GB projektu naprawdę odbywa się szybciej,
> >    jeśli odbywa się bez dostępu do sieci (w szczególności jeśli tą siecią
> >    jest internet),
>
> a) autor wątku ma raczej mały projekt (zgaduje)
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.

> b) moze zainteresuj się funkcja "switch" zamiast w kółko checkoutowac
Przecież w SVN-ie to leci po sieci. Czyli tak czy siak się czeka.

> > - Git ma "staging area" - to taka funkcjonalność, która sprawia, że
> >    nowy commit tworzą tylko te zmiany, które wskażesz. Możesz zmienić
> >    zawartość całego pliku, ale zdecydować się na zacommitowanie zmiany
> >    tylko np. w 3 pierwszych linijkach pliku,
>
> - Marek, masz tam tą poprawkę na buga 18876 ?
>   -No, mam, weź sobie te pliki, to pierwsze 25 linijek od 548 i jeszcze
> w 13445 zmień sobie warunek na większy. A, i jeszcze w pliku x.cpp jest
> do zmiany #define, w 15 lini
> - Ok, dzięki.
O, dowcip. Mało śmieszny co prawda.

> A zakładając że to powyzsze nie ma sensu to jaki sens ma commitowanie
> pół pliku na brancha na tyle często żeby miało to istotne znaczenie?
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. 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. A jak się pomylisz, to kaplica, bo poszło na serwer i się już
odkręcić tego nie da w żaden sposób.

> > - Git działa w trybie offline! Wydawałoby się, że jeśli w ciągu roku
> >    spędza się 2 dni poza biurem, to nie ma potrzeby używania
> >    rozproszonego VCS. Ale ja się w czasie tych dwóch dni w roku znalazłem
> >    w sytuacji, w której bez kopii projektu w repozytorium Gita bym sobie
> >    nie poradził,
>
> To jest jakis argument. Pytanie czy krytyczny na autora. Bo dla mnie ma
> wartośc bliską 0.
Patrz wyżej. Nie wyobrażam sobie (już), żeby zmiany szły na serwer od
razu podczas commita. 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ł. 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ć. Git daje mi taką możliwość, SVN nie.

> > - w dalszym ciągu uczę się zarządzania gałęziami tak, żeby potem nie
> >    pogubić się w gąszczu ;-), ale nie chciałbym nie mieć sprawnej obsługi
> >    gałęzi,
>
> Co jest *niesprawnego* poza duperelami w obsłudze gałęzi SVN?
Wszystko. Sam pomysł na realizację jest poroniony.

> Bo używam
> i nie placzę ani włosow nie wyrywam.
Ludzie wymieniający się kodem na dyskietkach pewnie też nie narzekają.

> Może po prostu wiem jak używać.
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ć? W SVN-ie taka gałąź będzie
widoczna do końca świata. W gicie dopiero wtedy, gdy ją opublikuję w
ten czy inny sposób.

> > - Git ma polecenie bisect, które znakomicie ułatwia znajdowanie
> >    commitów, które wprowadziły regresję.
>
> Obawiam się że zrobienie bisect za pomoca paru linijek bashu + svn nie
> stanowi żadnego kłopotu.
Chciałbym zobaczyć w jaki sposób te kilka linijek w bashu radzi sobie
z SVN-owymi merge'ami pozbawionymi historii.

> git nie wprowadza tutaj funkcjonalnie
> kompletnie nic.
Poza szybkością, gotowością rozwiązania, automatyzacją i możliwością
poprawienia błędu u źródła, a nie w późniejszym commicie. Ale poza tym
to zupełnie nic.