eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingSystem kontroli wersji.Re: System kontroli wersji.
  • Data: 2010-10-06 10:55:12
    Temat: Re: System kontroli wersji.
    Od: Sebastian Kaliszewski <s...@r...this.informa.and.that.pl> szukaj wiadomości tego autora
    [ pokaż wszystkie nagłówki ]

    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)

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: