Bodek wrote:
> On 5 Paź, 20:43, Sebastian Biały <h...@p...onet.pl> wrote:
>> Boszz... a miał być EOT.
> Ojej.
>
>> Ja byś kiedykolwiek używał SVNa
> Tobie się wydaje, że ja tu sobie tak konfabuluję bez jego znajomości?

To co wypisujesz wskazuje przynajmniej na brak oprzeczytania instrukcji
obsługi. Śrubokrętem też można wbijać gwoździe...

>
>> to być wiedział, że operacje typu zmiana
>> brancha sa natychmiastowe.
> Jakoś fakty temu przeczą.
>
>> 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.
> A ktoś poza tobą tego serwera używa? Bo u mnie sporo ludzi. I już tak
> pięknie nie jest.



>
>> Jesli mi teraz powiesz że git jest o
>> 450ms szybszy to pozostaje mi popukać się w czoło.
> Abstrahując od problemu, tak, 450ms to długi okres czasu. Zrób sobie
> 100 commitów i już czekasz 45 sekund dłużej.

ROTFL!

450ms w pracy interaktywnej to okres czasu bez znacznia. Chłopcy z IBM
to w latach 70-tych stwierdzili.

>
>> 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.
> Wspaniała opowieść, ale następnym razem jednak na temat proszę coś
> napisać.
>
>> Jesteś ekologiem ze żal Ci tych paru bitów na zrobienie osobnych
>> branchy?
> W SVN-ie? Nie, nie upadłem na głowę.
>
>> 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ą.
> Syntax error.
>
>> Jesli masz burdel na branchu to trudno się dziwić że masz burdel w
>> commitach.
> ROTFL.

Ale z tego co tu wypisujesz to właśnie na to wychodzi.


>> Mam prostą zasadę: jeden bug/feature - jeden branch. Jesli masz
>> zależoności to robisz po kolei. Sprawa prosta. A jaka wygodna.
> Ja pierdzielę. Rzeczywiście, super wygoda. Robić sobie 10 branchów (w
> SVN-ie), żeby zacommitować 10 onelinerów. Opad rąk, gaci, i w ogóle
> wszystkiego.

Owszem tak.

Bo inaczej to się sprowadza do commitowania kawałków o których nawet nie
wiadomo czy się skompilują. Czyli regularny burdel, ordynarnie mówiać.


>>> 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?
> I co, revert usunie mi commita z repozytorium? To o czym my tu
> rozmawiamy.

Wiesz po co są systemy kontroli wersji???

>
>> 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.
> Siądziesz kiedyś do nieswojego kodu, który _musisz_ naprawić na
> wczoraj, a tu kij wie co się dzieje, bo poprzedni programista naczytał
> się o wzorcach projektowych, ale nie do końca zrozumiał i kod jest nie
> do ogarnięcia, to zobaczysz jak się robi. Działa to działa, może nic
> się nie rozpieprzy, a nawet jeżeli to w QA wyłapią. Sorry. Na
> zapewnienie 100% poprawności nie dostaniesz po prostu zgody (=czasu
> (=pieniędzy)) i już.

Współczuję miejsca pracy.

Co i tak nie zmienia faktu, że w takiej sytuacji tym bardziej zmiany
*muszą* iść na serwer. Bo g... innych obchodzi że się czegoś wstydzisz,
ale przynajmniej następy poprawiający będzie widział co ruszałeś i gdzie
i może jemu prędzej się uda poprawić porządnie.


>> Albo robisz co chcesz na *branchu*, albo masz 100% pewności ze to co
>> komitujesz na *trunk* ma sens. Nie ma opcji w środku.
> Ja sobie robię fiu-bzdziu na masterze, a jak coś spieprzę to mogę
> poprawić. Dopiero jak wiem, że jest OK, to upubliczniam zmiany. W SVN-
> ie tak nie masz.



>
>>> 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.
> ROTFL. Ale ty wiesz, że ja to wszystko mam wersjonowane, tylko mogę
> sobie edytować (_wersjonowanie_), jak mi się podoba?

Czyli właśnie nie wiesz po co są systemy kontroli wersji...

>
>>> 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.
> Ha ha, dobry dowcip. Może w SVN-ie.



>
>>> Git daje mi taką możliwość, SVN nie.
>> a) nie widzialeś SVN na oczy.
> Oczywiście.

Tylko instrukcji nie przeczytałeś.

>
>> b) nie masz pojęcia jak sie sensownie pracuje (w obydwu systemach).
> Tak, w odróżnieniu od ciebie, co widać wyżej. I niżej.

Oj widać, widać... nie to co sobie wyobrażasz, niestety...

>
>> Jeśli potrzebujesz malego szkolenia to mogę pokazać. Wystarczy że dasz
>> znać. Mówie serio.
> No dawaj, chętnie posłucham jaki super jest SVN. Też mówię serio.
>
>>> 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.
> Też sobie mogę trzymać na branchu różne rzeczy, tylko nie wiem po co
> miałbym to pokazywać innym osobom.

Masz jakieś kompleksy?

Poza tym, w normalnym projekcie kompercyjnym, guzik kogo obchodzą twoje
kompleksy. Jeśli można zobaczyć co i jak zmieniałeś to i można poprawić.
A jak prąd wyłączą / dysk padnie albo się rozchorujesz to można kogoś
innego posadzić i będzie mógł robić od miejsca gdzie skończyłeś a nie od
0. Albo sam będziesz mógł robić na innej maszynie.


>>> 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?
> Ha ha. Ha. Nie, to nie jest śmieszne już. Ty na serio chcesz robić
> bisecta między rewizją 100 a 110 zaczynając od rewizji 105, nie
> zważając na to, że rewizje 100 i 110 są na trunku, a rewizja 105 jest
> na branchu dupa, który odchodzi od rewizji 50 i nie jest zmerge'owany
> do trunka?
>
>>> Poza szybkością
>> Jak w SVN z dokładnoscią do ms na małych projektach.
> ROTFL.
>
>>> gotowością rozwiązania
>> Jak w SVN.
> Sorry, ale w SVN nic do tego nie ma _gotowego_. Musisz sobie wyguglać,
> albo napisać sam.
>
>>> automatyzacją
>> Jak w SVN.
> Jw.
>
>>> i możliwością
>>> poprawienia błędu u źródła
>> Jak w SVN.
> ROTFL. U ŹRÓDŁA! POPRAWIENIE COMMITU Z BŁĘDEM! ROZUMIESZ?


NIE ROZUMIESZ DO CZEGO SA SYSTEMY KONTROLI WERSJI.

Po prostu zrobisz kolejny commit poprawiający błąd. A twoje kompleksy
dot. produkowanego kodu to twój prywatny problem a nie zespołu.

>
>>> a nie w późniejszym commicie.
> NIE W COMMICIE PÓŹNIEJSZYM!

ROTFL!

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

Z tego co wypisujesz to niestety wychodzi to co powyżej...

pzdr
\SK

--
"Never underestimate the power of human stupidity" -- L. Lang
--
http://www.tajga.org -- (some photos from my travels)