Boszz... a miał być EOT.

On 2010-10-05 19:58, Bodek wrote:
> 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.

Ja byś kiedykolwiek używał SVNa to być wiedział, że operacje typu zmiana
brancha sa natychmiastowe. 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. Z
czego wszystko to jazda po dysku. Jesli mi teraz powiesz że git jest o
450ms szybszy to pozostaje mi popukać się w czoło.

Na dużym repozytorium (kilkaset MB) switch trwa max pare sekund i ma
zwiazek z iloscią katalogów a nie wielkością plików (o ile ich nie zmienia).

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

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.

Jesteś ekologiem ze żal Ci tych paru bitów na zrobienie osobnych
branchy? Naprawdę, one czarodziejsko nie powiększają repozytorium a lasy
tropikalne nie cierpią. Ktoś te branche wymyślił w jakimś celu. 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ą.

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

Jesli masz burdel na branchu to trudno się dziwić że masz burdel w
commitach. Czy aby przypadkiem git nie ma narzędzi sworzonych dla
bałaganiarzy?

Mam prostą zasadę: jeden bug/feature - jeden branch. Jesli masz
zależoności to robisz po kolei. Sprawa prosta. A jaka wygodna. Że już o
testach regresyjnych nie wspomne. Ale gdzie mi się tam rownać z
profesjonalnym bisect ...

Od razu przyznaje że w SVN brakuje mi wygodnej mozliwości zrobienia
revert dla fragmentu pliku. Ale akurat to da się obejść zewnętrznymi
narzedziami, choć to upierdliwe.

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

> Patrz wyżej. Nie wyobrażam sobie (już), żeby zmiany szły na serwer od
> razu podczas commita.

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. Sorry że musialem Ci to uświadomić.
Albo robisz co chcesz na *branchu*, albo masz 100% pewności ze to co
komitujesz na *trunk* ma sens. Nie ma opcji w środku.

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

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

> Git daje mi taką możliwość, SVN nie.

Bo:

a) nie widzialeś SVN na oczy.

b) nie masz pojęcia jak sie sensownie pracuje (w obydwu systemach).

Jeśli potrzebujesz malego szkolenia to mogę pokazać. Wystarczy że dasz
znać. Mówie serio.

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

Setki razy. Tylko ze mi nie jest wstyd.

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

> 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? Pomijając fakt, że jak się nie ma burdelu to wykrywanie regresji
jest możliwe do zautomatyzowania po każdym commicie.

> Poza szybkością

Jak w SVN z dokładnoscią do ms na małych projektach.

> gotowością rozwiązania

Jak w SVN.

> automatyzacją

Jak w SVN.

> i możliwością
> poprawienia błędu u źródła

Jak w SVN.

, a nie w późniejszym commicie. Ale poza tym
> to zupełnie nic.

W gruncie rzeczy tak samo jak SVN.

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?

do góry

W dniu 2010-10-05 19:58, Bodek pisze:

Tak sobie czytam i w tym momencie prawie padłem.

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

> 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. Szkoda że nie
dociera do nich, że SVN jest wystarczający nawet dla dużych, ale
lokalnych, projektów. GIT najczęściej jest przerostem formy nad treścią.
Z tym że ja nie uważam SVNa za jedyne cudo warte używania i nie staram
się nikomu go narzucać/


--
pozdrawiam,
Przemek O.
SoftSYSTEM www.soft-system.pl
coś o jedzeniu www.kochamjedzenie.pl

do góry

Panowie się pokłócili o wyższość świąt, a mój problem nadal nie
rozwiązany. :-)

Przyznajmy, że każdy system ma swoje wady.
SVN daje dupy przy dużej ilości małych plików i mnogości katalogów, może
też winni są klienci, których używamy.
Z tego co zwolennicy pisali o GITcie to jak na system kontroli wersji to
pozwala na rzeczy nie do pomyślenia, np. usunięcie zmian po ich
opublikowaniu przynajmniej w mojej wyobraźni się nie mieści...

Zakończmy tę kłótnie proszę.


--
Pozdrawiam,
Andrzej

do góry

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

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

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

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

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

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

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

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

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

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

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

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

do góry

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

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

[*] 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.

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

--
Secunia non olet.
Stanislaw Klekot

do góry

On 2010-10-05, Andrzej W. <awa_wp.a_to_wytnij> wrote:
> Panowie się pokłócili o wyższość świąt, a mój problem nadal nie
> rozwiązany. :-)
>
> Przyznajmy, że każdy system ma swoje wady.
> SVN daje dupy przy dużej ilości małych plików i mnogości katalogów, może
> też winni są klienci, których używamy.
> Z tego co zwolennicy pisali o GITcie to jak na system kontroli wersji to
> pozwala na rzeczy nie do pomyślenia, np. usunięcie zmian po ich
> opublikowaniu przynajmniej w mojej wyobraźni się nie mieści...

Z grubsza rzecz biorąc, to usuwanie zmian po publikacji jest problemem
z metodologią postępowania. Na małą skalę (na małą odległość wstecz)
czasem się przepisywanie historii przydaje. Na dużą po prostu się tego
nie robi.

A tymczasem, jeśli chcesz mieć jakieś rozwiązanie, to przyznaj się jakie
masz możliwości w tym swoim hostingu. Na przykład czy to stoi na
Apache'u i jakie moduły masz/możesz mieć włączone. Bo w tej chwili
pytasz jak za pomocą młotka wkręcać śruby i starannie unikasz pełnego
opisania swojej sytuacji.

--
Secunia non olet.
Stanislaw Klekot

do góry

On 2010-10-05 22:09, Bodek wrote:
> Tobie się wydaje, że ja tu sobie tak konfabuluję bez jego znajomości?

Niewydaje mi się. Mam pewność.

>> to być wiedział, że operacje typu zmiana
>> brancha sa natychmiastowe.
> Jakoś fakty temu przeczą.

*Twoje* fakty. Moje nie. Potwierdzam codziennie. Po kilkanaście razy.

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

Kto *normalny* robi 100 commitów na godzinę żeby te 45 sek miało śladowe
znaczenie ?

>> Jesteś ekologiem ze żal Ci tych paru bitów na zrobienie osobnych
>> branchy?
> W SVN-ie? Nie, nie upadłem na głowę.

Ty ich nie robisz nawet w gicie. Albo inaczej: robisz jeden na dniówkę
wrzucajć tam co ci przyjdzie do głowy ze zbioru róznych poprawek a potem
podczas commitowania decydujesz co jest od czego. Spieprzyć można to tak
samo w svn jak i w gicie. Tylko może git jest bardziej tolerancyjny na
błedy metodyki pracy.

>> Jesli masz burdel na branchu to trudno się dziwić że masz burdel w
>> commitach.
> ROTFL.

<Ziew>

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

Sorry, ale tak to się robi. Jesli masz inną metodyke pracy to gratuluje.
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.

> I co, revert usunie mi commita z repozytorium? To o czym my tu
> rozmawiamy.

W efekcie końcowym *usunie* zmiany. Commit bedzie widoczy w historii,
zmian już nie bedzie. Przecież *dokładnie* to chcesz uzyskac w końcowym
efekcie. Usunąć zmiany. Niby dlaczego ma Ci zależeć w której rewizji to
nastąpi? Ważne że *już* ich nie ma.

> Siądziesz kiedyś do nieswojego kodu, który _musisz_ naprawić na
> wczoraj

Dzień jak codzień.

>, a tu kij wie co się dzieje, bo poprzedni programista naczytał
> się o wzorcach projektowych

Co to ma wspólnego z robieniem branchy?

>, ale nie do końca zrozumiał i kod jest nie
> do ogarnięcia, to zobaczysz jak się robi.

Dzien jak codzień.

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

Chyba nie rozumiesz idei. Nikt nie wymaga żeby poprawka robila 100% tego
co sie od niej wymaga. Natomiast przyjamniej mozna wymagać żeby
programista wkomitował to co chce nie myląc się przy komitowaniu które
linie ktorych plików sa tymi wlaściwymi. Sugerujesz ze potrzebujesz
podejmowac decyzje co wkomitować w momecie komitowania. Ja to zlewam -
robie merga z trunkiem i *wiem* ze komitują się zmiany potrzebne bo
tylko je posiadam na *tym* branchu. Co najwyzej spotka mnie konflikt. To
inne motody pracy, ale coś mi mówi ze niechęć do SVNa pochodzi własnie z
takiego niechlujstwa którego on nie wybacza.

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

To czego "nie mam" to jest branch i tam sobie moge pieprzyć dowoli.
Natomiast upublicznianie nazywa się mergowaniem z trunkiem. Widzisz
jakąs istotna róznicę poza fobią żeby ktoś nie widział twojego głupiego
kodu na branchu?

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, zazwyczaj nie mam ochoty
oglądac pośrednich wypocin innych.

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

Dalej zaprzeczasz podstawowej zasadzie istnienia systemów kontroli wersji.

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

Tak. Teraz wyjasnij jak zrozumialeś dowcip. Bo to nie był dowcip.

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

Nie. jak może zauważyles ja tutaj nie wciskam SVNa na siłę. Ja tu tylko
prostuje ewidentne kłamstwa na jego temat. Jesli chcesz wiedzieć jak
robic branche, jak mergować zmiany i jak uzywać to czemu nie. Ale że
jest jest super nie pokaże bo nie jest. Jest do dupy. Tylko troche mniej
niz git dla 2 osób. ba, Nawet znacznie mniej niz git dla *2* osób.

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

Nie rozumiem, biegasz po biurze z kartką "na branchu
/foo/23/testing/dupa mam straszne głupoty, patrzcie i komentujcie !"? To
jakis problem psychiczny że nie chcesz aby ktoś oglądał twoja
piaskownicę? Ludzie nie mają co robic tylko wymieniają się uwagami jak
ktoś cos na branchu spieprzył?

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

Zauważyleś słowo mediana a nie średnia? Bo pojawiło się nie bez powodu.
Jeśli nie to wpisz w google.

>>> gotowością rozwiązania
>> Jak w SVN.
> Sorry, ale w SVN nic do tego nie ma _gotowego_. Musisz sobie wyguglać,
> albo napisać sam.

Czego nie ma?

> ROTFL. U ŹRÓDŁA! POPRAWIENIE COMMITU Z BŁĘDEM! ROZUMIESZ?

Revert.

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

A jakaś to różnica po wykonaniu reverta? Jeśli jest to ją pokaż palcem.

do góry

W dniu 2010-10-05 22:59, Stachu 'Dozzie' K. pisze:

> A tymczasem, jeśli chcesz mieć jakieś rozwiązanie, to przyznaj się jakie
> masz możliwości w tym swoim hostingu. Na przykład czy to stoi na
> Apache'u i jakie moduły masz/możesz mieć włączone.


Jakoś w tej całej dyskusji nikt się o to nie zapytał.
Hosting najtańszy w abajt.pl
Apache, PHP, Perl, CGI, Python, MySQL, ftp, web disk.


--
Pozdrawiam,
Andrzej

do góry

On 5 Paź, 23:11, Sebastian Biały <h...@p...onet.pl> wrote:
> > Tobie się wydaje, że ja tu sobie tak konfabuluję bez jego znajomości?
> Niewydaje mi się. Mam pewność.
Polecam na przyszłość mniej buty.

> >> to być wiedział, że operacje typu zmiana
> >> brancha sa natychmiastowe.
> > Jakoś fakty temu przeczą.
> *Twoje* fakty. Moje nie. Potwierdzam codziennie. Po kilkanaście razy.
To opiszesz jak wygląda obciążenie twojego serwera, czy dalej będziesz
wycinał niewygodne fragmenty?

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

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

> Albo inaczej: robisz jeden na dniówkę
> wrzucajć tam co ci przyjdzie do głowy ze zbioru róznych poprawek
Słucham?

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

> Sorry, ale tak to się robi. Jesli masz inną metodyke pracy to gratuluje.
A dziękuję, ale nie ma czego gratulować. Daj znać jak już przestaniesz
się tłuc młotkiem po palcach, to też ci pogratuluję.

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

> > I co, revert usunie mi commita z repozytorium? To o czym my tu
> > rozmawiamy.
> W efekcie końcowym *usunie* zmiany. Commit bedzie widoczy w historii,
> zmian już nie bedzie.
Jak nie będzie, jak będą. Przeczysz sam sobie w jednym zdaniu.

> Przecież *dokładnie* to chcesz uzyskac w końcowym
> efekcie. Usunąć zmiany.
Nie, chce usunąć commita.

> Niby dlaczego ma Ci zależeć w której rewizji to
> nastąpi?
Dla mnie wartością jest nie tylko sam kod, ale również zapis procesu
jego powstawania. Robiąc burdel w commitach robisz burdel w kodzie, po
prostu. "Wlasnie zaprzeczyłeś sensowi istnienia systemów kontroli
wersji. Gratuluje."

> Ważne że *już* ich nie ma.
Może w twojej metodyce pracy.

> >, 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ć?

> Chyba nie rozumiesz idei. Nikt nie wymaga żeby poprawka robila 100% tego
> co sie od niej wymaga.
O, przepraszam.
--8<--
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. Sorry że musialem Ci to
uświadomić.
-->8--

Daj znać, jak już ustalisz sam ze sobą obowiązujący punkt widzenia.

> Natomiast przyjamniej mozna wymagać żeby
> programista wkomitował to co chce nie myląc się przy komitowaniu które
> 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.

> Ja to zlewam -
> robie merga z trunkiem i *wiem* ze komitują się zmiany potrzebne bo
> tylko je posiadam na *tym* branchu.
Rewelacja. To teraz mi wytłumacz jak na tym swoim SVN-ie realizujesz
rzecz następującą:
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.

> coś mi mówi ze niechęć do SVNa pochodzi własnie z
> takiego niechlujstwa którego on nie wybacza.
Idź do lekarza od głowy, jak głosy słyszysz.

> > 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.
> To czego "nie mam" to jest branch i tam sobie moge pieprzyć dowoli.
Nie możesz, bo branch jest publiczny.

> Natomiast upublicznianie nazywa się mergowaniem z trunkiem.
Zupełnie mylisz pojęcia.

> Widzisz
> jakąs istotna róznicę poza fobią żeby ktoś nie widział twojego głupiego
> kodu na branchu?
Twoja metodyka pracy nie przewiduje przeglądania mailing listy z
commitami?

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

> zazwyczaj nie mam ochoty
> oglądac pośrednich wypocin innych.
Aha.

> >> 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?
> Dalej zaprzeczasz podstawowej zasadzie istnienia systemów kontroli wersji.
Która polega na czym? Ta zasada?

> >> I tu nagle odkrywasz branche i reverty. Gratuluje.
> > Ha ha, dobry dowcip. Może w SVN-ie.
> Tak. Teraz wyjasnij jak zrozumialeś dowcip. Bo to nie był dowcip.
Nie może być!!!

> >> 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.
> Nie.
No i tyle w temacie. To SVN-a też nie używałeś?

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

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

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

> >>> gotowością rozwiązania
> >> Jak w SVN.
> > Sorry, ale w SVN nic do tego nie ma _gotowego_. Musisz sobie wyguglać,
> > albo napisać sam.
> Czego nie ma?
Gotowego rozwiązania.

> > ROTFL. U ŹRÓDŁA! POPRAWIENIE COMMITU Z BŁĘDEM! ROZUMIESZ?
> Revert.
A ty dalej powtarzasz wyuczone hasełka.

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

do góry

On 2010-10-05, Andrzej W. <awa_wp.a_to_wytnij> wrote:
> W dniu 2010-10-05 22:59, Stachu 'Dozzie' K. pisze:
>
>> A tymczasem, jeśli chcesz mieć jakieś rozwiązanie, to przyznaj się jakie
>> masz możliwości w tym swoim hostingu. Na przykład czy to stoi na
>> Apache'u i jakie moduły masz/możesz mieć włączone.
>
>
> Jakoś w tej całej dyskusji nikt się o to nie zapytał.
> Hosting najtańszy w abajt.pl
> Apache, PHP, Perl, CGI, Python, MySQL, ftp, web disk.

To znaczy masz tam możliwość włączenia WebDAV-a czy nie? Bo ja nie
jestem nawet ich klientem.

--
Secunia non olet.
Stanislaw Klekot

do góry