W dniu niedziela, 2 grudnia 2012 17:36:53 UTC użytkownik e...@g...com
napisał:
> A dlaczego niby "o k..."? I tak robie backup. Zmieniam katalog nadysk sieciowy
> i robie przed wyjsciem z pracy "git clone" - robi to w minute kopie 1:1
> wszystkiego co mam lokalnie przy milionach linii kodu i mnostwie wygenerowanych
> plikow, dodatkowo w bezpieczny sposob. Wiec zostaje i laptop i kopia sieciowa,
> nawet gdybym mial odejsc z pracy rzucajac wszystko momentalnie w p..u.

W sytuacji "Edek zlamal noge i nie przyjdzie do pracy, Felek musi przejac prace nad
pilna poprawka nad ktora Edek pracowal w zeszlym tygodniu", to wyglada tak (dla
odpowiedniego duzego korpo):

1. svn, branch jest w repo: Felek robi "svn checkout" i po paru minutach
zaglebia sie w kod Edka, przeklinajac brak komentarzy i kryptyczne nazwy
zmiennych (j/k)
2. git, branch jest lokalny: szef grupy sle maila do helpdesku proszac o
skopiowanie kodu Edka z jego komputera; czas reakcji: 2-3 godziny

To jest oczywiscie troche wydumana sytuacja, ale moze sie zdarzyc.

RW

do góry

On 2012-12-02, Sebastian Biały <h...@p...onet.pl> wrote:
>> No ale widzisz, w svn robisz zmiany, potem kompilujesz i wypada puscic testy
>> i dopiero commit. W git juz jak sie kompiluje sprawdzam cale zmiany
>> i robie commit. Jak sie nie skompiluje lub nie dziala, poprawiam juz
>> zrobiony commit ("--amend") - nikt nigdy nie zobaczy schrzanionego commita.
>
> Dlaczego ma nie zobaczyć? Albo rewertujesz albo commitujesz fixa. Nie
> rozumie, dlaczego wśród gitowców jest tak powszechne oszukiwanie (tu nie
^^^^^^^-- kto nie rozumie? czy "ja nie rozumię"?
> bylo żadnego commita!). Praca z repo z rewizjami wymaga pewnej higieny
> która wychodzi na zdrowie.

Praca z rewizjami wymaga pewnej higieny. Taką higieną jest nietrzymanie
pomyłki po wsze czasy, tylko (o ile nie została jeszcze opublikowana)
poprawienie jej w miejscu.

Kwestia przyjętej strategii. W Subversion nie poprawiasz, tylko łatasz,
bo nie masz wyboru. W gicie to kwestia polityki.

> Dalej nie jestem przekonany, twoje argumenty nie pokazują żadnej
> lepszosci gita nad svnem w przypadku o który chodziło (jak się okazuje)
> autorowi wątku.

Bo Edek nie przemyślał swoich argumentów. To, jak zauważyłem, normalne
przy dyskusjach o systemach kontroli wersji. Nikt zachwalający swój
ulubiony system kontroli wersji nie potrafi pokazać, dlaczego jest on
(naj)bardziejszy.

> Przyznaje, że jestem gotowy przejśc na gita pod
> warunkiem natrafienia na jeden killer-feature vs svn, bo drobnostki w
> svn są upierdliwe.

W podstawowym zastosowaniu git nie ma specjalnej przewagi nad
Subversion, wyjąwszy pracę odłączoną. Ja zaczynałem naukę gita od mostka
git-svn, żeby móc pracować na nie-zawsze-połączonym-z-internetem-laptopie
nad kodem znajdującym się oryginalnie w Subversion.

W porównaniu z Subversion git ma znacznie lepsze mechanizmy śledzenia
operacji merge. Ja na ten przykład do tej pory nie nauczyłem się, jaka
jest realna różnica między `svn merge' i `svn merge --reintegrate' na
długo żyjących branchach (z czasem następuje zamiana ról i merge
z trunka do brancha musi dostać --reintegrate; nadal nie wiem dlaczego
ani kiedy).

Informacja o merge'ach nie jest czymś dosztukowanym za pomocą atrybutów,
tylko jedną z podstawowych cech commita, przez co trudniej o głupią
pomyłkę. Zdarzyło mi się parę razy zacommitować merge bez katalogu
głównego, przez co svn:mergeinfo poszło w pizdu. Owszem, da się w SVN
z tego wycofać, ale dlaczego to w ogóle było możliwe?

Obliczanie różnic między commitami odbywa się na lokalnej maszynie,
a nie na serwerze, który służy do współdzielenia kodu. Przy większych
repozytoriach jest to istotna różnica.

W sytuacji, gdy praca nad kodem odbywa się w sieci, która nie ma żadnego
połączenia z siecią, gdzie ten kod pracuje produkcyjne, łatwiej jest
przerzucać commity. Mam taki specjalny workflow, który mi pakuje różnice
między tym, co powinno być w sieci produkcyjnej i bieżącym stanem,
a potem te zmiany przenoszę "na pendrajwie"[*], gdzie je wciągam do
produkcji.

[*] W rzeczywistości w nieco inny sposób, ale zgodnie z tym samym
schematem.

Przepisywanie historii w gicie pozwala mi na następujący sposób pracy
z gałęziami: wszystkie commity lokalne dla brancha są nałożone *na*
brancha źródłowego, a nie z nim *wymieszane*. W historii widać to tak,
że najpierw czyta się wyłącznie lokalne zmiany, a od pewnego momentu już
są same commity z oryginalnego brancha.
Jeśli mam tylko dwa-trzy commity w lokalnym branchu i ta liczba się nie
zwiększy drastycznie (np. w webaplikacji z raportami dodany jest dla
wygody jeden URL do dokumentacji), to łatwiej jest porównywać branch
oryginalny z lokalnym i wciągać zmiany z oryginalnego (tzn. nie
"konflikty są mniejsze", tylko "łatwiej znaleźć, które commity były tu,
a które tam i co jeszcze nie zostało zmerge'owane").

Git ma wbudowaną możliwość składania podpisów GPG pod commitami. Jeszcze
z tego nie korzystałem, ale gdy będę potrzebować systemu dystrybucji
informacji, w którym odbiorca ufa nie źródłu informacji (serwerowi),
a samym informacjom, w gicie będzie mi to łatwiej zrobić niż w SVN.

--
Secunia non olet.
Stanislaw Klekot

do góry

W dniu poniedziałek, 3 grudnia 2012 16:09:22 UTC+1 użytkownik Roman W napisał:
> W dniu niedziela, 2 grudnia 2012 17:36:53 UTC użytkownik e...@g...com
napisał:
> > A dlaczego niby "o k..."? I tak robie backup. Zmieniam katalog nadysk sieciowy
> > i robie przed wyjsciem z pracy "git clone" - robi to w minute kopie 1:
> > wszystkiego co mam lokalnie przy milionach linii kodu i mnostwie wygenerowanych
> > plikow, dodatkowo w bezpieczny sposob. Wiec zostaje i laptop i kopia sieciowa,
> > nawet gdybym mial odejsc z pracy rzucajac wszystko momentalnie w p..u.

> W sytuacji "Edek zlamal noge i nie przyjdzie do pracy, Felek musi przejac prace nad
pilna poprawka nad ktora Edek pracowal w zeszlym tygodniu", to wyglada tak (dla
odpowiedniego duzego korpo):

> 1. svn, branch jest w repo: Felek robi "svn checkout" i po paru minutach
> zaglebia sie w kod Edka, przeklinajac brak komentarzy i kryptyczne nazwy
> zmiennych (j/k)
>
> 2. git, branch jest lokalny: szef grupy sle maila do helpdesku proszac o
> skopiowanie kodu Edka z jego komputera; czas reakcji: 2-3 godziny

> To jest oczywiscie troche wydumana sytuacja, ale moze sie zdarzyc.

Nie, nie moze ;) Jak tak mi zyczycie to ja sobie ide w p..u. A z tym Felkiem
to dobre.

--
Edek

do góry

W dniu poniedziałek, 3 grudnia 2012 16:13:34 UTC+1 użytkownik Stachu 'Dozzie' K.
napisał:

> Bo Edek nie przemyślał swoich argumentów. To, jak zauważyłem, normalne
> przy dyskusjach o systemach kontroli wersji. Nikt zachwalający swój
> ulubiony system kontroli wersji nie potrafi pokazać, dlaczego jest on
> (naj)bardziejszy.

Ja tylko dyskutowalem z argumentami, o innych przewagach gita to ja moglbym
walnac kilka tak dlugich postow.

PGP uzywam: jak administruje systemami to robie checkout odpowiedniej wersji
i dzieki PGP wiem, ze to oryginal, choc trzymam to na malo pewnej stronie.
Wolalbym nie miec rootkita w domyslnej konfiguracji. No i wszystko mam
wersjonowane, czyli moge cherry-pickiem przerzucic jedna zmiane pomiedzy
branchami czyli konfiguracjami.

Wybrane:
mam lokalna konfiguracje rozwijanego systemu, sciezki, rozmiary i takie tam.
A w zasadzie dwie konfiguracje, klaster na laptopa i zwykla.

Dodatkowo mam swoje lokalne instrumentalizacje kodu do debuggowania. To
sporo plikow, mod systemu builda i pare innych.

I teraz co daje git: powiedzmy, ze mam zgloszenie, ze w wersji 4.5.43 jest
blad. Robie tak:
git checkout -b test1 <odpowiedni commit>
git merge moj_lokalny_konfig
git merge instrumentalizacja

... i mam wszystko gotowe do zbudowania i testow, podczas gdy recznie
- zajeloby mi to z pol godziny
- moglbym cos nadpisac, np. zmiany w globalnym konfigu, a git sprawdzi,
czy nie ma konfliktow
- w svn gdyby kazdy trzymal takie rzeczy w publicznym bylby smietnik.
A mamy master, kilka tagow, branche release, i chyba ze 3-4 inne branche
- jak ktos chce moj lokalny konfig, moge mu wyslac branch mailem jedna
komenda i to faktycznie dziala.

Rowniez, w tym samym celu, mam drugie lokalne repo ze wszystkimi kombinacjami
konfigow, instrumentalizacji i wersji release. Wiec jak mam przetestowac
ostatnie zmiany robie "git pull" i mam wszystkie wersje skonfigurowane
tak jak lubie w 5 sekund na odpowiednich branchach.

Itd. itp.

--
Edek

do góry

On 03/12/2012 15:13, Stachu 'Dozzie' K. wrote:
> On 2012-12-02, Sebastian Biały <h...@p...onet.pl> wrote:
>
> W porównaniu z Subversion git ma znacznie lepsze mechanizmy śledzenia
> operacji merge. Ja na ten przykład do tej pory nie nauczyłem się, jaka
> jest realna różnica między `svn merge' i `svn merge --reintegrate' na
> długo żyjących branchach (z czasem następuje zamiana ról i merge
> z trunka do brancha musi dostać --reintegrate; nadal nie wiem dlaczego
> ani kiedy).

Reintegrate jest ci potrzebny wtedy, kiedy na branchu, który mergujesz
bezpośrednio przedtem zmergowałeś zmiany z brancha docelowego.
Reintegrate nie merguje ci wtedy wszystkich zmian wstecz, tylko aktualną
różnicę między branchem mergowanym a docelowym, uwzględniając
automatycznie przez samo to na przykład wszystkie rozwiązane po drodze
konflikty.

Powiedzmy wybranchowujesz sobie trunka, robisz na nim jakieś zmiany, po
jakimś czasie wciągasz na brancha zmiany z trunka, rozwiązujesz
konflikty, poprawiasz żeby działało, robisz jakieś dalsze zmiany i tak
dalej. W końcu masz już całą funkcjonalność na branchu, więc dociągasz
zmiany z trunka i w tym momencie branch jest taki saqm jak trunk, tylko
że ma twoje zmiany. Robisz merge --reintegrate, i trunk staje się
identyczny z twoim branchem. Tada!

do góry

W dniu poniedziałek, 3 grudnia 2012 16:09:22 UTC+1 użytkownik Roman W napisał:
> W sytuacji "Edek zlamal noge i nie przyjdzie do pracy, Felek musi przejac prace nad
pilna poprawka nad ktora Edek pracowal w zeszlym tygodniu", to wyglada tak (dla
odpowiedniego duzego korpo):
>
> 1. svn, branch jest w repo: Felek robi "svn checkout" i po paru minutach
> zaglebia sie w kod Edka, przeklinajac brak komentarzy i kryptyczne nazwy
> zmiennych (j/k)
>
> 2. git, branch jest lokalny: szef grupy sle maila do helpdesku proszac o
> skopiowanie kodu Edka z jego komputera; czas reakcji: 2-3 godziny
>
> To jest oczywiscie troche wydumana sytuacja, ale moze sie zdarzyc.

Nie do końca. Kolega stracił kiedyś kilka dni pracy zapisanych w lokalnym
branchu (git). Od tego czasu mamy *obowiązek* na koniec dnia pushować
swoje feature branche na zdalne repo.

BTW, czy SVN ma coś takiego jak interactive rebase?

w.

do góry

On 2012-12-14, Wojciech Muła <w...@g...com> wrote:
> W dniu poniedziałek, 3 grudnia 2012 16:09:22 UTC+1 użytkownik Roman W napisał:
>> W sytuacji "Edek zlamal noge i nie przyjdzie do pracy, Felek musi przejac prace
nad pilna poprawka nad ktora Edek pracowal w zeszlym tygodniu", to wyglada tak (dla
odpowiedniego duzego korpo):
>>
>> 1. svn, branch jest w repo: Felek robi "svn checkout" i po paru minutach
>> zaglebia sie w kod Edka, przeklinajac brak komentarzy i kryptyczne nazwy
>> zmiennych (j/k)
>>
>> 2. git, branch jest lokalny: szef grupy sle maila do helpdesku proszac o
>> skopiowanie kodu Edka z jego komputera; czas reakcji: 2-3 godziny
>>
>> To jest oczywiscie troche wydumana sytuacja, ale moze sie zdarzyc.
>
> Nie do końca. Kolega stracił kiedyś kilka dni pracy zapisanych w lokalnym
> branchu (git). Od tego czasu mamy *obowiązek* na koniec dnia pushować
> swoje feature branche na zdalne repo.
>
> BTW, czy SVN ma coś takiego jak interactive rebase?

SVN w ogóle nie ma rebase. Dlaczego nagle miałby się dorobić trybu
interaktywnego?

--
Secunia non olet.
Stanislaw Klekot

do góry