On 2010-10-06 00:18, Bodek wrote:
> To opiszesz jak wygląda obciążenie twojego serwera, czy dalej będziesz
> wycinał niewygodne fragmenty?

Nie wiem jak wygląda obciążenie *mojego* serwera w domu, raczej jest
mizerne. Ale serwera na którym *pracuje* wygląda na kilkadziesiąt osób i
kilkadziesiąt MB kodu. Działa. Zaskakująco sprawnie.

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

>> Ty ich nie robisz nawet w gicie.
> Nie, nie widzę powodu dla którego miałbym robić sobie osobne branche
> tylko po to, żeby zacommitować na nie zmianę jednej linijki, a potem
> od razu zmerge'ować do mastera.

Nie potrzebujesz wobec tego branchy. Bo twój branch z kilkunastoma
poprawkami jest tylko zbytkiem bitów. Po prostu edytuj pliki wprost na
trunku.

>> a potem
>> podczas commitowania decydujesz co jest od czego.
> Ale ty pierdzielisz od rzeczy.

Raczej potwarzam zasłyszane:

- 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

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

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

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

>> linie ktorych plików sa tymi wlaściwymi. Sugerujesz ze potrzebujesz
>> podejmowac decyzje co wkomitować w momecie komitowania.
> Tak, potwierdzam. Oczywiście że potrzebuję. Nie wiem tylko co to ma
> wspólnego z tym co sobie ubzdurałeś i mi cały czas wmawiasz.

Powyżej masz cytat.

> 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 (bo na branch
mogę)? Jaki jest cel który uzyskam komitując te pierdoły pojedynczo?
Jaki *rzeczywisty* a nie wymyślony powód sugeruje merge pojedyncze?

(co gorsza twoje pytanie ma odpowiedź w SVN ale chciałbym najpier
zapytać *PO* co).

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

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

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

>>> No dawaj, chętnie posłucham jaki super jest SVN. Też mówię serio.
>> Nie.
> No i tyle w temacie. To SVN-a też nie używałeś?

Przyciąłeś za dużo. Nie będę przekonywał o superowatości SVNa bo to jest
gównaniy system kontroli wersji. Ale git jest gównie gównaniy, a nawet
bardziej w zastosowaniu z którego powstał ten watek.

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

>> 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. Interesują Cie zmiany na
trunku. Tam je oglądasz, a jak jesteś rozsądnym człowiekiem to commity
trunkowe są przepuszczane *najpierw* przez code review i pilnowane przez
automatyke do wykrywania regresji.

>> Zauważyleś słowo mediana a nie średnia? Bo pojawiło się nie bez powodu.
> Wytłumacz mi jak to tam działa z tymi merge'ami, bo mi się to w głowie
> nie mieści.

W trunku masz rewizje:

123
150
189
197
230

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

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

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