Stachu 'Dozzie' K. wrote:
>>> Dowiedź że jest gorszy.
> [mowa o Perlu]
>> <Ziew>. Niby jak? Jakie są warunki gorszości ktore Cie przekonają?
>> Nieczytelność kodu źrodłowego jest wystarczająca?
>
> Czyjego? Kretynów nieumiejących pisać programów? Żadna wada, to samo
> jest w dowolnym innym języku.
>
>>> O? To komitet Perla nadużywa alkoholu podczas zatwierdzania propozycji
>>> składniowych? Pierwsze słyszę. Możesz podać źródło tych rewelacji?
>> Obserwacje własne wyniku ich pracy
>
> ORLY? Których części wyniku ich pracy?


ROTFL!

Język którego zachowanie jest niezdefiniowane *z zasady* (np.
interpolacja stringów), gdzie różne elementy parsera "głosują" nad wynikiem.

Wszelkie obrzydliwości w rodzaju:

%{$zmienna}, $$zmienna, \%zmienna, itd...
$cośtam->{owośtam} vs $cośtam{owośtam} vs $cośtam[owośtam] vs
$cośtam->[owośtam]...
naście sposobów "quotowania"...
@cośtam znaczy co innego zależnie od sytuacji...
itd...


słowem executable line noise.

>> i opinie ludzi pracujacych zawodowo w
>> Perlu - wnioski nasuwają się niejako automatycznie.
>
> Dziwne. Znam ludzi mających cokolwiek krytyczne nastawienie do używanego
> języka, ale nigdy nie słyszałem od nich zarzutu nadużywania alkoholu
> przez komitet.

Bo po moejemu to ne był alkohol, tylko coś "twardszego" ;)

>
>> I są identyczne jak
>> w PHP, tylko żed w PHP przy okazji byli jeszce dodatkowo po ciężkiej
>> imprezie w akademiku.
>
> Od PHP proszę się tu odpierwiastkować. W tej części mówimy o Perlu.
>


Sposób powstania obu języków podobny (chaotyczna zbieranina pomysłów i
rozwiązań, często wzajemnie sprzecznych)

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

do góry

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)

do góry

On 6 Paź, 07:33, Sebastian Biały <h...@p...onet.pl> wrote:
> mizerne. Ale serwera na którym *pracuje* wygląda na kilkadziesiąt osób i
> kilkadziesiąt MB kodu. Działa. Zaskakująco sprawnie.
No no, kilkadziesiąt MB, fiu fiu. Będziesz miał rozmiar repo liczony w
GB to porozmawiamy o wydajności.

> >> Kto *normalny* robi 100 commitów na godzinę żeby te 45 sek miało śladowe
> >> znaczenie ?
> > Poczytaj sobie na przykład o metodologii pracy Linusa.
> Po co?
Po jajco. Bo w możliwość zmiany twoich poglądów jakoś nie wierzę.

> Przeciez 100 commitów na godzinę jest *bzdurą*.
Tak tak, oczywiście. Brnij dalej.

> Nie potrzebujesz wobec tego branchy. Bo twój branch z kilkunastoma
> poprawkami jest tylko zbytkiem bitów. Po prostu edytuj pliki wprost na
> trunku.
Znowu się pogubiłeś? "Sorry, ale tak to się robi. Jesli masz inną
metodyke pracy to gratuluje."

> >> a potem
> >> podczas commitowania decydujesz co jest od czego.
> > Ale ty pierdzielisz od rzeczy.
> Raczej potwarzam zasłyszane:
Widzę, że powtarzasz co usłyszysz. Szkoda tylko, że nie rozumiesz.

> >> U mnie tworzenie brancha trwa tak krótko ze nie ma sensu sie rozwodzić
> >> nad tym dłużej niż 1 sek czasu potrzebnego na jego stworzenie.
> > Śmieszne.
> Ba, a jakie prawdziwe.
Nie przeczę. Niemniej, czekanie 1 sekundę na coś, co w gicie jest
natychmiastowe jest śmieszne.

> > Nie, chce usunąć commita.
> Czyli wymazać historię.
No i? Mimo, że dla ciebie oznacza to koniec świata, ludzie z tego
korzystają.

> Sorry, SVN na tym nie polega.
Niesamowite! Fajnie że mi o tym powiedziałeś, bo wcześniej nie
wiedziałem.

> W rewizji 12345 była regresja. Nie wiemy jednak dlaczego bo jakiś
> miszczu usunął historię a po tygodniu okazało się że ta regresja to
> progresja.
Historii opublikowanych zmian raczej się nie zmienia. W każdym razie,
nawet jakby, to u nikogo poprzednia historia repozytorium nagle nie
zniknie.

> > Robiąc burdel w commitach robisz burdel w kodzie, po
> > prostu.
> To jest historia.
"Ci, którzy nie pamiętają przeszłości, skazani są na jej powtarzanie."

> >> Ważne że *już* ich nie ma.
> > Może w twojej metodyce pracy.
> Myslę że w repo.
W repozytorium są, sam pisałeś coś o świętości commitów.

> >>> , a tu kij wie co się dzieje, bo poprzedni programista naczytał
> >>> się o wzorcach projektowych
> >> Co to ma wspólnego z robieniem branchy?
> > A co ma niby mieć?
> No własnie pytam co mają wzorce do robienia branchy, przeciez to twój
> przykład.
Bardzo mi przykro, że nie rozumiesz słowa pisanego.

> > Daj znać, jak już ustalisz sam ze sobą obowiązujący punkt widzenia.
> To ze rozumiesz coś inaczej nie oznacza że inni mają rozdwojenie jaźni.
> Moze nalezy czytać między wierszami, coś się domyślić.
Może należy nauczyć się pisać tak, żeby było wiadomo o co chodzi.

> > Masz moduł A, interfejs B, implementację C. Dodajesz do interfejsu B
> > nic nie robiącą metodę wirtualną, którą implementujesz w C, a
> > wywołujesz z A. Oczywiście, dopóki nie upewnisz się, że wszystko na
> > 100% działa (zmiany w A, B, C są zaimplementowane), nic nie
> > commitujesz. Dla porządku, zmiany w B, A, C commitujesz osobno (przy
> > podanym porządku commitów zmiany są atomowe). Wytłumacz jak to
> > osiągnąć na SVN-ie, przy założeniu że wszystkie zmiany były robione
> > tylko w jednym pliku.
> Teraz wyjaśnij mi *po* co mam je mergować osobno na trunk
Jakie merge'owanie? Ja pytałem o robienie commitów.

> Jaki jest cel który uzyskam komitując te pierdoły pojedynczo?
Czystość historii kodu? A nie, przepraszam, dla ciebie repozytorium to
wór do którego wrzucasz wszystko jak leci, w końcu liczy się tylko
czubek brancha.

> >> To czego "nie mam" to jest branch i tam sobie moge pieprzyć dowoli.
> > Nie możesz, bo branch jest publiczny.
> Gówno prawda. Branch to publiczna piaskownica. Mozesz tam wkladać co
> chcesz i potem to zlewać, psuć kod, generować dowolne błędy i regresje.
> jest rzecza niezrozumiałą po co miałby ktoś to śledzić poza paranoją.
Śmieszny jesteś, wiesz?

> Wiec co jest upublicznianiem kodu w/g Ciebie?
http://sjp.pwn.pl/szukaj/upublicznienie

> > Twoja metodyka pracy nie przewiduje przeglądania mailing listy z
> > commitami?
> Z branchy? Te kilkadziesiąt na godzinę? Sorry, ale nie.
To dużo tłumaczy.

> >> Moze po prostu inaczej rozumiemy upublicznianie. ja jako upublicznianie
> >> rozumiem wrzucenie w główne źrodła. A to że ktoś na branchu wrzucił
> >> sobie zdjęcia porno mało mnie interesuje
> > Ciekawe co by na to powiedział klient.
> Czepiasz się słów
Jakbym się czepiał słów, to bym cię odesłał z powrotem do szkoły.
Ilość błędów które robisz jest niesamowita.

> gubiąc przesłanie.
To nie ja podałem przykład z pornosami na repo, więc nie odkręcaj
teraz kota ogonem.

> Klient nie ma dostepu do branchu.
To bardzo ciekawe, biorąc pod uwagę, że klient może wymagać
znajdowania się repozytorium na jego serwerze.

> Kilenta nie obchodzi jak została przygotowany commit.
Może twoich nie obchodzi.

> Że kazda zmiana jest w historii. Sugerujesz że git moze manipulowac
> histrią.
Nie kłam. Jawnie go za to chwalę.

> To źle bo to nie jest potrzebne.
Bredzisz.

> >> Ludzie nie mają co robic tylko wymieniają się uwagami jak
> >> ktoś cos na branchu spieprzył?
> > Ja staram się orientować co się w kodzie dzieje. Bez patrzenia na
> > zmiany było by trochę ciężko, ale pewnie mi zaraz powiesz jak to w
> > twojej metodyce pracy wygląda.
> *Nie* chcesz oglądać zmian na branchach.
U mnie nikt nie wrzuca pornoli na repozytorium.

> Interesują Cie zmiany na
> trunku. Tam je oglądasz
Mam się patrzeć na jakieś code bomby zmieniające tysiące linii kodu i
dotykające prawie każdego pliku w projekcie, zamiast na malutkie
commity zmieniające jedną, konkretną rzecz? Dobrze się czujesz?

> Robisz switch to revision 189 i sprawdzasz regresje. Nie ma? To robisz
> switch do 150 i sprawdzasz. Nie ma? To na 123. Listę rewizji na trunku
> svn z przyjemnością wyrzuci jesli go poprosisz.
Zdajesz sobie sprawę z tego, jak wygląda repozytorium po merge'u w
systemach kontroli wersji które nie były projektowane przez bandę
szympansów?

> Informajca z ktorego brancha to pochodzi w SVN jest (od niedawna o ile
> pamiętam) ale jest *zbedna* żeby wykonać ta operację.
Bzdura.

> Szambo tak naprawdę nie istnieje. Nie wpływa na cokolwiek. Jest
> przezroczyste. Jesli masz z tym problem to może to jest tylko Twoj problem.
Śmiech na sali.

do góry

Sebastian Biały wrote:
[...]
>> Nie, chce usunąć commita.
>
> Czyli wymazać historię. Sorry, SVN na tym nie polega. Commit jest
> święty. Właśnie po to sa rewizje.
>
>> Dla mnie wartością jest nie tylko sam kod, ale również zapis procesu
>> jego powstawania.
>
> W rewizji 12345 była regresja. Nie wiemy jednak dlaczego bo jakiś
> miszczu usunął historię a po tygodniu okazało się że ta regresja to
> progresja.
>
>> Robiąc burdel w commitach robisz burdel w kodzie, po
>> prostu.
>
> To jest historia. Po wykonaniu reverta repozytorimu jest w taki samym
> stanie jak przed pierowtym commitem, jedyna róznica to inne numerki. 0
> burdelu. Albo pokaż palcem gdzie on jest poza dyskomfortem psychicznym.
>
>>> Ważne że *już* ich nie ma.
>> Może w twojej metodyce pracy.
>
> Myslę że w repo.
>
[...]
>>> To czego "nie mam" to jest branch i tam sobie moge pieprzyć dowoli.
>> Nie możesz, bo branch jest publiczny.
>
> Gówno prawda. Branch to publiczna piaskownica. Mozesz tam wkladać co
> chcesz i potem to zlewać, psuć kod, generować dowolne błędy i regresje.
> jest rzecza niezrozumiałą po co miałby ktoś to śledzić poza paranoją.
>
>>> Natomiast upublicznianie nazywa się mergowaniem z trunkiem.
>> Zupełnie mylisz pojęcia.
>
> Wiec co jest upublicznianiem kodu w/g Ciebie? Commit na brancha? Jeśli
> masz paranoje na punkcie podglądania cudzego kodu to można zastosować
> prawa dostępu żby nikt Twoich zmian nie oglądał. Dalej nie rozumiem po co.

Też nie wiem... Jak ktoś się wstydzi swojego kodu, to chyba nie powinien
być programistą...

>
>> Twoja metodyka pracy nie przewiduje przeglądania mailing listy z
>> commitami?
>
> Z branchy? Te kilkadziesiąt na godzinę? Sorry, ale nie.
>
>>> Moze po prostu inaczej rozumiemy upublicznianie. ja jako upublicznianie
>>> rozumiem wrzucenie w główne źrodła. A to że ktoś na branchu wrzucił
>>> sobie zdjęcia porno mało mnie interesuje
>> Ciekawe co by na to powiedział klient.
>
> Czepiasz się słów gubiąc przesłanie. Klient nie ma dostepu do branchu.
> Kilenta nie obchodzi jak została przygotowany commit. Ważne że podczas
> mergowania do trunka jest kompletny, sprawdzony i przetestowany.

Ba, "u mnie" klienta nie ma dostępu do trunka też. Repozytorium to rzecz
wewnętrzna. Klient dostaje release, każdy release oparty jest o branch,
branch najczęściej zdegenerowany, to znaczy zawierający tylko jedną
wersję -- czasem jak mają być poprawki dla danego release i wtedy jest o
1-2 wersje więcej (np. wszystko jest już "na produkcji" i zmiany
minimalizujemy tylko do konkretnej poprawki poważnego problemu.


>>> Dalej zaprzeczasz podstawowej zasadzie istnienia systemów kontroli
>>> wersji.
>> Która polega na czym? Ta zasada?
>
> Że kazda zmiana jest w historii. Sugerujesz że git moze manipulowac
> histrią. To źle bo to nie jest potrzebne.

Ba, to jest szkodliwe!

1. Historia jest dla mnie, po to bym po 5 latach, pracując na zupełnie
innej maszynie (bo poprzednia poszła "z dymem" jak jakoś "się udało"
zwalić otwartą colę na komputer), mógł prześledzić zmiany i te dobre i
te złe, by odtworzyć co mi chodziło po głowie.
2. Historia jest dla innych, gdy ja będę na urlopie / chory / zmienię
pracę by podobnie jak wyżej mogli zorientować się "co poeta miał na myśli".


MAm tylko wrażenie, że niektó?zy dyskutancie nie bardzo wyobrażają sobie
"po 5 latach" bo 5 lat to (dużo) więcej niż czas w jakim programują
zawodowo.

[...]
>>> To
>>> jakis problem psychiczny że nie chcesz aby ktoś oglądał twoja
>>> piaskownicę?
>> "zazwyczaj nie mam ochoty oglądac pośrednich wypocin innych."
>> A ja nie jestem ekshibicjonistą i nie mam ochoty innym pokazywać moich
>> pośrednich wypocin.
>
> Więc to problem czysto psychiczny. Kwestia przełamania się.

Ba, programista który chce coś ukrywać to problem dla reszty zespołu.
Odwyk konieczny i to szybko!

>>>> ROTFL. U ŹRÓDŁA! POPRAWIENIE COMMITU Z BŁĘDEM! ROZUMIESZ?
>>> Revert.
>> A ty dalej powtarzasz wyuczone hasełka.
>
> Nie, to metodyka pracy z SVN.

Nie tylko z SVN -- to po prostu sensowna metodyka pracy. Ukrywanie zmian
i poprawianie historii to *szkodliwy debilizm*. Nie ważne czy w git czy
w svn czy cvs czy w hg.

[...]
>>>>>> a nie w późniejszym commicie.
>>>> NIE W COMMICIE PÓŹNIEJSZYM!
>>> A jakaś to różnica po wykonaniu reverta?
>> Taka, że nie jestem badziewiarzem patrzącym się tylko na to co jest na
>> masterze/trunku/HEAD i przeszkadza mi szambo w historii projektu.
>
> Szambo tak naprawdę nie istnieje. Nie wpływa na cokolwiek. Jest
> przezroczyste. Jesli masz z tym problem to może to jest tylko Twoj problem.

Jeśli praktykuje "odstawianie takiego badziewia" w zespole to jest to i
problem zespołu.

pzdr

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

do góry

Stachu 'Dozzie' K. wrote:
> On 2010-10-06, Sebastian Biały <h...@p...onet.pl> wrote:
>>>> Kto *normalny* robi 100 commitów na godzinę żeby te 45 sek miało śladowe
>>>> znaczenie ?
>>> Poczytaj sobie na przykład o metodologii pracy Linusa.
>
>> Po co? Przeciez 100 commitów na godzinę jest *bzdurą*.
>
> "Nie wiem czy to ma sens, ale nie będę czytał czy ma sens, bo nie ma
> sensu". A skąd pomysł że to commity przygotowane *przez niego*?

I tak łatpię w 100 na godzinę. A jeśli nawet to 45s w ciągu godziny to
różnica nieistotna.

>
>>> Robiąc burdel w commitach robisz burdel w kodzie, po
>>> prostu.
>
>> To jest historia. Po wykonaniu reverta repozytorimu jest w taki samym
>> stanie jak przed pierowtym commitem, jedyna róznica to inne numerki. 0
>> burdelu. Albo pokaż palcem gdzie on jest poza dyskomfortem psychicznym.
>
> Ano tu: commitujesz przez pomyłkę nieprawidłowo opisując rewizję. Na
> przykład złym numerem buga. A potem weź szukaj w historii poprawki na to
> co zrobiłeś.

Robisz revert i commit z właścimym opisem. Co za problem?


>>>> To czego "nie mam" to jest branch i tam sobie moge pieprzyć dowoli.
>>> Nie możesz, bo branch jest publiczny.
>
>> Gówno prawda. Branch to publiczna piaskownica. Mozesz tam wkladać co
>> chcesz i potem to zlewać, psuć kod, generować dowolne błędy i regresje.
>> jest rzecza niezrozumiałą po co miałby ktoś to śledzić poza paranoją.
>
> Z daleka widać że nie miałeś do czynienia z kodem pisanym dla dużego
> klienta. Wierzysz że managierzy takiej Nokii czy innego Sony Ericssona
> mają ciekawsze rzeczy do roboty?

Owszem mają.

BTW -- my robimy na swoim repozytorium -- (bardzo) dużego klienta
obchodzi skończony kod (release) a nie nasze repozytorium...

>
>>>> Natomiast upublicznianie nazywa się mergowaniem z trunkiem.
>>> Zupełnie mylisz pojęcia.
>
>> Wiec co jest upublicznianiem kodu w/g Ciebie?
>
> Zapewne wystawienie go w taki sposób, że ktokolwiek inny niż autor (np.
> kolega z projektu albo przedstawiciel klienta) może ten kod obejrzeć.

No i dobrze że kolega może ten kod obejrzeć. Może czegoś się nauczy. A
może znajdzie błąd w podejściu.


>> Commit na brancha? Jeśli
>> masz paranoje na punkcie podglądania cudzego kodu to można zastosować
>> prawa dostępu żby nikt Twoich zmian nie oglądał. Dalej nie rozumiem po co.
>
> Żeby managier od klienta nie jojczał że "ten kod się nie nadaje,
> niedopuszczalne, zrywamy umowę!".

Gdzie tak debilnie podpisano umowę, że managier patrzy w rozgrzebany kod
i ma coś do powiedzenia???

Tu trzeba zacząć on naprawy debilnego układu.


>>>> Moze po prostu inaczej rozumiemy upublicznianie. ja jako upublicznianie
>>>> rozumiem wrzucenie w główne źrodła. A to że ktoś na branchu wrzucił
>>>> sobie zdjęcia porno mało mnie interesuje
>>> Ciekawe co by na to powiedział klient.
>
>> Czepiasz się słów gubiąc przesłanie. Klient nie ma dostepu do branchu.
>
> Z dokładnością do sytuacji gdy sobie zażyczy takiego dostępu. Co wcale
> nie jest takie rzadkie.

Życzyć sobie może i gwiazdki z nieba. W cywilizowanej produkcji to samo
życzenie jest rzadkie. A spełnienie życzenia jeszcze rzadsze.


>> Robisz switch to revision 189 i sprawdzasz regresje. Nie ma? To robisz
>> switch do 150 i sprawdzasz. Nie ma? To na 123. Listę rewizji na trunku
>> svn z przyjemnością wyrzuci jesli go poprosisz.
>
>> Informajca z ktorego brancha to pochodzi w SVN jest (od niedawna o ile
>> pamiętam) ale jest *zbedna* żeby wykonać ta operację.
>
> Czyli dostajesz coś w rodzaju "ja wiem co się zepsuło! samochód się
> zepsuł!". Przejście przez historię merge'owania pozwala dokładniej
> wyizolować błąd.

Ale żeby zrobić bisect sam w sobie jest zbędna. BTW -- a jak
potrzebujesz, to jest dostępna.


>>>>>>> a nie w późniejszym commicie.
>>>>> NIE W COMMICIE PÓŹNIEJSZYM!
>>>> A jakaś to różnica po wykonaniu reverta?
>>> Taka, że nie jestem badziewiarzem patrzącym się tylko na to co jest na
>>> masterze/trunku/HEAD i przeszkadza mi szambo w historii projektu.
>
>> Szambo tak naprawdę nie istnieje. Nie wpływa na cokolwiek.
>
> Chyba że na wyszukiwanie informacji w historii.

W jaki sposób?

>
>> Jest
>> przezroczyste. Jesli masz z tym problem to może to jest tylko Twoj problem.
>
> Widać nigdy nie potrzebowałeś przeglądać historii szukając konkretnych
> informacji.
>

ROTFL!

BArdzo często to robi. I dlatego chcę wszystkie informacje a nie
podedytowane przez wstydliwego programistę.

pzdr

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

do góry

Stachu 'Dozzie' K. wrote:
> On 2010-10-05, Przemysław Osmański <p...@o...eu> wrote:
>> W dniu 2010-10-05 19:58, Bodek pisze:
>
>>> 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.
>> A mi taką możliwość daje środowisko programistyczne. Kontrola wersji,
>> też zintegrowana ze środowiskiem, jest raczej dodatkiem do niego a nie
>> narzędziem które ma za nie odwalić połowę roboty. Chyba że używasz
>> notatnika lub czegoś jego pokroju.
>
> Przepraszam, czy ja dobrze rozumiem? Masz IDE, które oprócz integracji
> z systemem kontroli wersji ma własny system kontroli wersji?
>
> Zaznaczam że ja się od IDE trzymam z daleka[*] i po prostu chcę wiedzieć
> czy ja czegoś o tym typie narzędzi nie wiem.
>
> [*] Inna sprawa że nie piszę nic co ma więcej niż kilka KLOC-ów,

Czyli masz mocno nietypową jak na programistę robotę. A więc należy się
spodziewać i nietypowych wymagań.

za to
> często piszę w różnych językach i uczenie się osobnego IDE dla każdego
> języka to albo by był overkill, albo by mi było niewygodnie w każdym
> ze środowisk.

Jest parę IDE wielojęzycznych...

>
>>> 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.
>> Po tym co tutaj czytam i moich testach gita, wydaje mi się, że zagorzali
>> jego obrońcy używają go tylko dlatego że jest taka moda.
>
> Nieprawda. Wcześniej używałem głównie Subversion. Gita zacząłem używać,
> bo to był jedyny znany mi[*] system kontroli wersji, który miał
> sensownie rozwiązany interfejs do dwukierunkowej komunikacji
> z Subversion (potrzebne mi były operacje przy braku dostępu do serwera
> SVN). A potem przesiadłem się całkiem. Nie dlatego że moda, tylko
> dlatego że było mi wygodniej.

Patrz wyżej [typowość wymagań].

>
> [*] Potem się okazało że mogłem użyć SVK. Ale na chwilę wyboru nie
> znałem go.
>
>> Szkoda że nie
>> dociera do nich, że SVN jest wystarczający nawet dla dużych, ale
>> lokalnych, projektów.
>
> Do momentu gdy trzeba więcej pracować z gałęziami. Póki masz bardzo
> prosty workflow, to SVN wystarczy.
>
>> GIT najczęściej jest przerostem formy nad treścią.
>
> Ę? Znaczy w którym miejscu? Bo podstawowy workflow jest z grubsza taki
> sam co SVN, tylko więcej opcji masz na wierzchu.

GIT łatwiej pozwala na zrobienie kompletnego burdelu, pogubienie połowy
historii itd. W przypadku małego (w tym zdegenerowanego do 1 os) zespółu
to nie ma problemu, ale w przypadku dużych zespołów owszem -- i w
jednych lepiej sprawdzi się git (projekty typu linux, mozilla, itd) a w
inncyh svn ("centralnie sterowane")


>
>> Z tym że ja nie uważam SVNa za jedyne cudo warte używania i nie staram
>> się nikomu go narzucać/
>

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

do góry

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

Tego typu postępowanie to jedna z przyczyn powstawania w większych
firmach patologii zwanej "ukrytymi fabrykami".

M.in. z tego powodu SVN jest jednak preferowany w większych firmach.

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

Ale można zmienić w kolejnych rewizjach. Jest to transparentne dla
pozostałych osób zaangażowanych w projekt, za to umożliwia lepsze
rozliczanie programisty.

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

j/w

Poza tym, SVN w naturalny sposób zapobiega chomikowaniu sobie prywatnych
gałęzi kodu. Chcesz pracować, to rób to na oficjalnym serwerze.

Żadnych ukrytych fabryk - jeśli powstaje w firmie jakiś problem, to się
go powinno naprawiać, a nie obudowywać jakimiś procesami pośrednimi,
które go tylko zamaskują i pozwolą pracownikom utrzymywać status quo.


Pozdrawiam

Patryk

do góry

>> To jest historia. Po wykonaniu reverta repozytorimu jest w taki samym
>> stanie jak przed pierowtym commitem, jedyna róznica to inne numerki. 0
>> burdelu. Albo pokaż palcem gdzie on jest poza dyskomfortem psychicznym.
>
> Ano tu: commitujesz przez pomyłkę nieprawidłowo opisując rewizję. Na
> przykład złym numerem buga. A potem weź szukaj w historii poprawki na to
> co zrobiłeś.

1. No więc może *przede wszystkim* programista powinien się bardziej
skupiać na pracy, zamiast wyręczać się narzędziami?

Zgadza się, to się zdarza - ale jest to też dość mocno skorelowane z
tym, że jedni programiści mają po prostu większy potencjał i większe
doświadczenie od innych. I takie rzeczy należy w większych
firmach/projektach wychwytywać i wykorzystywać, a nie ukrywać. Ukrywanie
jest bowiem korzystne tylko i wyłącznie dla samego programisty, a nie
dla tego, kto za tą całą zabawę płaci.


2. W SVN *da się* zmienić opis rewizji - po prostu jest to zablokowane
domyślnie i wymaga odblokowania na serwerze repozytorium. Właśnie po to,
aby móc dostosować politykę blokowania do hierarchii w firmie/projekcie,
np. tylko kierownik ma prawo to zrobić, dodatkowo w nowym opisie musi
się znaleźć numer zadania w Tracu, Jirze itp. z uzasadnieniem.


Pozdrawiam

Patryk

do góry

W dniu 2010-10-03 13:37, Andrzej W. pisze:
> Witam,
>
> Szukam systemu kontroli wersji, który będę bazował tylko na serwerze www
> i bazie danych MySQL bez konieczności dostępu do shella.
>


Idąc za wskazaniami Kolegów szukałem czegoś rozsądnego pod hasłem
"WebDAV" no i rozproszonego.
Niestety po przeanalizowaniu dostępnych VCS wyszło na to, że ich
wsparcie dla WebDAV, jeśli jest to głównie w skwerze marzeń.
Najbliżej był Git, ale też sobie nie poradził z moim dyskiem sieciowym.

Dopiero po zamapowaniu dysku sieciowego za pomocą netdrive jako dysku
lokalnego dało się tego używać.
netdrive niestety nie jest darmowa a i sam pomysł mapowania tego jako
dysku lokalnego też mi się nie podoba.



--
Pozdrawiam,
Andrzej

do góry

On 2010-10-06 12:41, Bodek wrote:
> No no, kilkadziesiąt MB, fiu fiu. Będziesz miał rozmiar repo liczony w
> GB to porozmawiamy o wydajności.

Kilkadziesiąt MB na trunku. Rozmiar repo kilkanascie GB. Porozmawiamy?

>> Przeciez 100 commitów na godzinę jest *bzdurą*.
> Tak tak, oczywiście. Brnij dalej.

<Ziew> Mocny argument. Pass.

>> Nie potrzebujesz wobec tego branchy. Bo twój branch z kilkunastoma
>> poprawkami jest tylko zbytkiem bitów. Po prostu edytuj pliki wprost na
>> trunku.
> Znowu się pogubiłeś? "Sorry, ale tak to się robi. Jesli masz inną
> metodyke pracy to gratuluje."

Nipotrzebie rozbisz brancha dla 10 poprawek. To się niczym nie różni od
poprawiania wprosta na trunku. Burdel ten sam, roboty mniej.

>>> Nie, chce usunąć commita.
>> Czyli wymazać historię.
> No i? Mimo, że dla ciebie oznacza to koniec świata, ludzie z tego
> korzystają.

Ludzie korzystają głównie z windowsa. Czy mam z tego powodu twierdzić że
jest najlepszy na świecie?

>> W rewizji 12345 była regresja. Nie wiemy jednak dlaczego bo jakiś
>> miszczu usunął historię a po tygodniu okazało się że ta regresja to
>> progresja.
> Historii opublikowanych zmian raczej się nie zmienia. W każdym razie,
> nawet jakby, to u nikogo poprzednia historia repozytorium nagle nie
> zniknie.

Przeciez wlasnie to postulowaleś.

>>>> Ważne że *już* ich nie ma.
>>> Może w twojej metodyce pracy.
>> Myslę że w repo.
> W repozytorium są, sam pisałeś coś o świętości commitów.

W repo jest HEAD i tam nie ma. Jesli potrzebujesz coś więcej to jest to
sytuacja wyjątkowa i *wtedy* masz dostęp. W HEAD już nie ma. To jest cel
który osiągasz revertem. W zasadzie jedyny potrzebny.

> Bardzo mi przykro, że nie rozumiesz słowa pisanego.

Zauważam za dużą ilość osobistych wycieczek.

>> Teraz wyjaśnij mi *po* co mam je mergować osobno na trunk
> Jakie merge'owanie? Ja pytałem o robienie commitów.
>> Jaki jest cel który uzyskam komitując te pierdoły pojedynczo?

Spójnośc poprawki. Wkomitowanie pustej metody której nikt nie używa poza
sporadycznymi przypadkami jest bezcelowe. Rozbijanie commita na 10
poprawek wymaga potem wiedzy tajemnej zeby za miesiąc poprawki usunąc, o
ile to w ogóle wykonalne automatycznie.

> Czystość historii kodu? A nie, przepraszam, dla ciebie repozytorium to
> wór do którego wrzucasz wszystko jak leci, w końcu liczy się tylko
> czubek brancha.

Liczy się tylko czubek trunka. Pozostałe czubki mam w ... a nie, nie dam
Ci satyfakcji łapania za slowa.

> Śmieszny jesteś, wiesz?

Kolejna osobista wycieczka. Przestalem juz liczyć.

> Ilość błędów które robisz jest niesamowita.

Bo jestem leniem z definicji.

>> gubiąc przesłanie.
> To nie ja podałem przykład z pornosami na repo, więc nie odkręcaj
> teraz kota ogonem.

Przykaład z pornosami w branchu znam osobiście w pewnym projekcie.
Leżały przez rok zanim sie ktoś zorientował. To tyle w temacie
przeglądania branchów przez ludzi z zewnątrz.

>> Klient nie ma dostepu do branchu.
> To bardzo ciekawe, biorąc pod uwagę, że klient może wymagać
> znajdowania się repozytorium na jego serwerze.

To jest klient specyficzny. Powiedzmy że żadko spotykany. Trudno
dyskutowac ogólnie. Wszystkie przypadki które znam nie pozwalają na
wgląd w kod pośredni, sporadycznie zezwala się na zaglądanie w trunk.
Najczęsciej klient dostaje kod w postaci plików a nie repo. Jesli masz
inaczej to masz mało typowo.

> Bredzisz.

Osobista wycieczka N+1.

>> *Nie* chcesz oglądać zmian na branchach.
> U mnie nikt nie wrzuca pornoli na repozytorium.

Wrzucają cos równoważnego - kod którego się wstydzą (od klienta po kolegów).

> Mam się patrzeć na jakieś code bomby zmieniające tysiące linii kodu i
> dotykające prawie każdego pliku w projekcie, zamiast na malutkie
> commity zmieniające jedną, konkretną rzecz? Dobrze się czujesz?

Niektorych rzeczy nie da się spójnie zaimplemetowac w sposob malutki i
jednocześnie spójny. Przykro mi. Od ogladania kodu jest code review a
nie diffy z repo. Commity ktore zmieniają prawie wszystkie pliki w
projekcie to jest zwykły science-fiction poza przypadkami zmiany z \r na \n.

> Zdajesz sobie sprawę z tego, jak wygląda repozytorium po merge'u w
> systemach kontroli wersji które nie były projektowane przez bandę
> szympansów?

Zazwyczajw 100% jak się tego spodzewiasz: jeden komit na trunk i
prawidłowe zmiany w plikach, operacja jest atomowa i trunk jest stabilny
w sensie kompilacji przed i po (o ile programiści mają taki wymóg).

>> Informajca z ktorego brancha to pochodzi w SVN jest (od niedawna o ile
>> pamiętam) ale jest *zbedna* żeby wykonać ta operację.
> Bzdura.

Więc udowodnij tezę przeciwną.

do góry