W dniu niedziela, 2 grudnia 2012 19:05:59 UTC+1 użytkownik Sebastian Biały napisał:
> On 2012-12-02 18:36, e...@g...com wrote:

> >> W svn wszystko da się cofnąć. Ale od razu kasować? Wybranchowanie nie
> >> zajmuje *nic* w repo.
> > Oprocz tego, ze zostaje widoczny branch (wiesz, to pbyla pomylka i
> > tak zostalo).

> Jak widzisz jedynym powodem kasowania branchy jest zwykły wstyd. Popsuło
> się? I co z tego? Jesli masz porządek w branchach dodatkowy nic nie
> przeszkadza.

Tu nie chodzi o wstyd. Mi nawet nie jest wstyd, jak popsuje wszsytkim builda
i testy - bo to sie zdarza w dowolnym systemie kontroli wersji.

Chodzi - mi przynajmniej - o latwosc i szybkosc korzystania. Nie lubie,
jak mnie repozytorium meczy, jak musze mega uwazac, wole zajac sie praca
nad kodem.

> > No ale widzisz, w svn robisz zmiany, potem kompilujesz i wypada puscic testy
> > i dopiero commit. W git juz jak sie kompiluje sprawdzam cale zmian
> > i robie commit. Jak sie nie skompiluje lub nie dziala, poprawiam juz
> > zrobiony commit ("--amend") - nikt nigdy nie zobaczy schrzanionego commita.

> Dlaczego ma nie zobaczyć? Albo rewertujesz albo commitujesz fixa. Nie
> rozumie, dlaczego wśród gitowców jest tak powszechne oszukiwanie (tu nie
> bylo żadnego commita!). Praca z repo z rewizjami wymaga pewnej higieny
> która wychodzi na zdrowie.

Nie wiem skad pomysl, ze w git nie ma "higieny".

Nie ma tez oszukiwania: wszystko co sie wypchnie do wspolnego repo zostaje.
Natomiast wygodnie jest lokalnie poprawiac zanim sie wypchnie. "Amend" jest
nawet w GUI, bo jest wygodne - po co komu w historii zepsuty commit i
revert lub poprawka nic nie wnoszaca, moze byc jeden dobry commit. Jako
ze amend sluzy do poprawki jednego commita, da sie tez poprawic commity
pod spodem, ale za pomoca kilku komend - znowu, o ile wciaz sa lokalne.
Nawet da sie odzyskac usuniete niby na zawsze rzeczy lub makabrycznie
schrzaniony merge. Mi sie podoba to, ze nie musze tak mega uwazac i ze
moge bezkarnie robic bledy, bo ja czasem robie bledy. Jak te bledy moge
poprawic zanim sa na master (cvs trunk) lub nawet na wspolnym branchu,
to z tego korzystam.

> > Z SVN byl to odwieczny problem, przy 100 deweloperach czesto zdarzaly
> > sie nie udane buildy, bo ktos sie pomylil.
>
> Zaryzykuje że to nie ilośc developerow ale poziom komplikacji kodu ma
> większe znaczenie. A "nieudane" buildy to jest możliwe w kazdej sytuacji
> bez względu na kontrole wersji. Na szczęscie procesy zapewniające
> integralnośc buildu dają się łatwo automatyzować (o ile nie ma się
> burdelu ...).

U nas to sie zdarza, budujemy wiele wersji i czasem jedna czy dwie sie
nie zbuduja. Za duzo czasu wymagaloby budowanie wszystkiego lokalnie
dla sprawdzenia. Ale i tak jest latwiej niz z svn.

> > Usuwa sie branche, ktore sa juz zmergowane zupelnie w innym celu. W
> > przeciwienstwie do svn zostaje pelna historia commitow z brancha - daty,
> > autorzy, opisy itd.

> Tak samo w svn.

No wlasnie nie tak samo, to jedna z glownych zalet gita.

> > . Taki usuwany branch staje sie historia
>
> *DOKŁADNIE* o to chodzi. Przypadek z tego tygodnia: musiałem wygrzebać
> branch mniej więcej z zeszłego roku. Był. Mialem tam niedokończoną
> implementację która była teraz jak znalazł.

No ale niedokonczonych sie nie usuwa, po co.

> >>> Jak to "gdzie on mial te pliki"? W repo, jak zawsze.
> >> Ktorym? Lokalnym? O k...
> > A dlaczego niby "o k..."? I tak robie backup. Zmieniam katalog nadysk sieciowy
> > i robie przed wyjsciem z pracy "git clone" - robi to w minute kopie 1:1
> > wszystkiego co mam lokalnie przy milionach linii kodu i mnostwie wygenerowanych
> > plikow, dodatkowo w bezpieczny sposob.

> Zupełnie jak svn commit?

Ano nie, nie jak svn commit.

> Dalej nie jestem przekonany, twoje argumenty nie pokazują żadnej
> lepszosci gita nad svnem w przypadku o który chodziło (jak się okazuje)
> autorowi wątku. Przyznaje, że jestem gotowy przejśc na gita pod
> warunkiem natrafienia na jeden killer-feature vs svn, bo drobnostki w
> svn są upierdliwe.

OP mowil, ze na poczatku chce pracowac lokalnie. Git wymaga stworzenia
katalogu i jednej komendy. Stawianie repo svn wymaga znacznie wiecej czasu.

EOT, nie sadze zeby ta dyskusja kogokolwiek juz interesowala.
--
Edek