GNOME przejdzie na git

Źle się wyraziłem. Rozważa, a nie planuje.

@Bananikus: Roznic jest masa, od wydajnosci po backupy, ale w wielkim skrocie: git sprawdza sie duzo lepiej niz svn w przypadku, jesli masz duzo developerow dzialajacych w sposob niezorganizowany i tanich.

http://www.youtube.com/watch?v=4XpnKHJAok8 – wstęp do idei Gita.

Bardzo interesujące wystąpienie Linusa.

A tutaj Google TechTalks na temat Mercurial Project
http://video.google.com/videoplay?docid=-77242960…

@Bananikus: decentralizacja, praca offline, lokalne branchowanie, szybkość, łatwe i skuteczne merge’owanie.

Decentralizacja — każdy ma pełnoprawną kopię repozytorium, z/do której ludzie mogą ciągnąć/wrzucać, dzięki czemu grupa ludzi może sobie coś tam rzeźbić na boku synchronizując się między sobą, bez zaśmiecania centralnego repo branchami, a nawet nie mając prawa zapisu do niego.

Praca offline — można spokojnie developować np w samolocie commitując sobie lokalnie zmiany (dzięki czemu mamy historię, z której w razie czego można się wycofać), a potem hurtem wrzucić zmiany do centralnego repo albo wysłać je jako patche komuś innemu.

Lokalne branchowanie — każda kopia repo jest pełnoprawnym repozytorium, więc można sobie lokalnie porobić kilka branchy, na których się testuje swoją radosną twórczość, albo na których prowadzimy poszczególne tematy (tak korzystam z gita w pracy[*] — mam N tematów, które wolę trzymać osobno, żeby ograniczyć liczbę zmiennych w czasie testów, więc dla każdego sobie zrobiłem brancha i między nimi skaczę).

Szybkość — generalnie błysk ciupagi nawet na dużych repozytoriach (kernel = 10MLOC).

Merge’owanie — maszynka do merge’owania jest o wiele skuteczniejsza niż ta w svn (automatycznie wykrywa zmiany nazwy pliku, mniej konfliktów itp), a samo propagowanie zmian w dowolną stronę jest trywialne (z mainstreama na moje branche — git rebase; w drugą stronę – git merge).

[*] W pracy centralnie używamy CVS, ale ja sobie po checkoucie z CVS wciągam to do gita i robię branche, na których rzeźbię swoje rzeczy, tak więc na „master” mam zawsze czysty CVS a na branchach swoje zmiany, które jeszcze nie są gotowe, żeby trafić do CVS.

Sychronizacja z centralnym repo — git co master; cvs up; git add .; git ci -m „nr_buildu_z_cvs”; git co moj_lokalny_branch; git rebase master. Po takiej operacji na branchu mam moje zmiany przeniesione na źródła z cvs i mogę pracować na aktualnym kodzie.

Przenoszenie moich zmian — git co master; git merge moj_lokalny_branch; cvs ci -m „…”

Żyć nie umierać :)

> Merge’owanie — maszynka do merge’owania jest o wiele skuteczniejsza niż ta w svn

Czyli trzymanie sie monolitow dalej? Linus jest niereformowalny. Przeciez system mergowania to zadanie samo w sobie i powinien byc czyms w rodzaju plugina do syst.kontroli wersji.

Sporo z pozostalych rzeczy to takze kawalki do wyodrebnienia. Np. co system na serwerze obchodzi, ze user sobie utworzyl nawet i milion galezy w swojej kopii? Serwer obchodzi co on dostaje do commita, a nie jak sobie tam rzezbil to user.

No ale coz… skoro nadal postep wyznacza rekompilowanie kernela, zeby dzwiek zadzialal… to git ;-/

Ktoś rozumie zrzędzenie maciasa i przetłumaczy?

@Rsh macias narzeka, że Linus (twórca Gita) wybrał budowę monolotyczną (żadnych pluginów)

a kawałek o rekmpilowaniu kernela to hasełka populistyczne w stylu "podwyżki dla wszystkich"

@przemo_li: Raczej "populistyczne" haselka w stylu "dlaczego u nas nie moze byc tak jak u innych".

Bo GIT jest trendy. Osobiście śledzę rozwój tego systemu i mercuriala od początku, każdy z nich ma swoje wady i zalety, różnią się głównie w koncepcji przechowywania zmian, i to mocno rzutuje na to jak radzą sobie w różnych sytuacjach. GIT musi być odśmiecany co jakiś czas, mercurial nie wymaga żadnej dodatkowej administracji. GIT przede wszystkim zarządza zawartością w przeciwieństwie do mercuiriala, który bierze pod uwagę nie tylko pliki ale również moment commitu, dzięki czemu zapamiętuje więcej informacji potrzebnych do mergowania. Dzięki temu repozytorium GIT-a jest bardziej kompaktowe (bo bo jeśli jest kilka identycznych plików to używany jest tylko jeden obiekt do przechowywania zawartości), ale jest duży problem z takimi operacjami jak śledzenie zmian nazw plików czy znacznie mniej efektywna operacja annotate do czego Linus zdążył dorobić zresztą już całą folozofię (IMHO naciąganą). Te operacje w mercurialu są wspierane natywnie, ale ten z kolei ma (póki co) duży narzut związany z zapamiętywaniem informacji po zmianie nazwy pliku (jest praktycznie zdublowana).

Inne jest też podejście do tagowania. GIT traktuje tagi jako zewnętrze referencje do wersji a mercurial wersjonuje swój plik z tagami jak każdy inny. Jest to dość kontrowersyjna decyzja Matta Mackalla (twórca mercuriala), który nie wiedzieć czemu uparł się, że właśnie tak jest dobrze i trzyma się tego kurczowo mimo iż racjonalne argumenty wydają się przemawiać za rozwiązaniem konkurencji (po części jest to też związane z kompatybilnością wsteczną, która jest jednym z priorytetów tego projektu). Skończyło się na tym, że jest dostępne rozszerzenie 'bookmarks', które dodaje funkcjonalność zewnętrznych tagów, z jednym wszakże drobnym mankamentem – nie propagują się automatycznie przy klonowaniu…

Kolejną kwestią jest przenośność, mercurial nie ma obecnie większych problemów w działaniu WindowsUnix. Jeśli się pamięta, żeby uzywać rozszerzenia win32text pod Windows i nie używa tych samych nazw plików pod Uniksem (wielkość liter), to można z powodzeniem rozwijać przenośne projekty (Mozilla, Java, NetBeans, Xen, etc.). GIT formalnie ma swój post pod cygwinem i ostatnio także msysgit, ale mało kto chce pod windows używać cygwina, a msysgit wciąż jest bardziej betą niż pełnoprawnym portem git-a pod Windows.

Na koniec dwie kwestie. Jedna to łatwość obsługi, i tu niestety mimo deklarowanych chęci developerów GIT-a, mercurial wciąż pozostaje niedoścignionym wzorem dla nich, a druga to społeczność. Otóż o ile można śmiało powiedzieć, że GIT ma znacznie więcej użytkowników/developerów to trzeba też przyznać, że często zachowują się IMHO jak świadkowie Jehowy. Nie dość, że uważają swój system za jedynie słuszny to jeszcze próbują go wcisnąć wszędzie i każdemu, co potrafi być irytujące. W każdym razie myślę, że swój sukces GIT zawdzięcza w dużej mierze właśnie tej "ewangelizacji", bo żeby zacząć go używać w pełni efektywnie to trzeba najpierw trochę wyrzeczeń.

Obydwu tych rzeczy nie da się powiedzieć o jego konkurencie (nikt się nikomu nie narzuca, a narzędzia używa się naprawdę intuicyjnie i łatwo, co potwierdza wielu użytkowników).

@pijaczek: coś mi się widzi, że w życiu nie pracowałeś przy dużym projekcie korzystającym z kontroli wersji.

W systemach scentralizowanych również można sobie tworzyć branche developerskie (w przypadku badziewnego CVS można go sobie zrobić tylko na swoim module albo wręcz na pojedynczym pliku) i na nich pracować nie afektując całej reszty świata. Przewaga systemów rozproszonych to to, że nie trzeba tymi swoimi branchami zaśmiecać centralnego repo, i to, że prawo zapisu do centralnego repozytorium może mieć mniejsza liczba osób (np tylko szefowie grup wrzucają zmiany do głównego, a cała reszta ekipy pracuje na repozytach swoich szefów).

Można zrobić branch, ale koszt zrobienia takiego jest nieporównywalnie większy niż np. w git, a do zrobienia ich trzeba mieć dostęp do serwera, a w wypadku git gałęzie są trzymane nie w branch na serwerze głównym, a na na komputerach grupy dlatego systemy rozproszone (i dodatkowo grupa może sobie zrobić kilka branchów, łatwo i bez robienia śmietnika z głównego serwera). Systemy rozproszone mają przewagę zarówno w firmach, jak i w wolnym oprogramowaniu.

@pijaczek: przecież dokładnie to napisałem

@pijaczek: I twoim zdaniem latwiej zorganizowac backup dla wszystkich tych serwerow, niz ustawic prawa dostepu dla kilku osob na centralnym?

@trasz: jaka to różnica czy serwer pobierze kopie z serwera głównego, czy z listy serwerów? Tyle samo danych do pobrania, a korzyści w przy pracy duże.

@pijaczek: zasadnicza. Zwłaszcza, jeśli ludziom zdarza się być w rozjazdach i tylko od czasu do czasu łączyć się przez VPN.

@ufoludek: to wtedy też nie wysyłają na svn i też nie zrobisz backup'a tych danych, czyli gdzie jest ta zasadnicza różnica?

@ufoludek: Wszystko to mozna zrobic tez z SVN – na czas rozwijania kodu robi sie po prostu oddzielnego brancha. Trwa to moment dluzej niz z SVN, ale to roznica rzedu, przy duzych repo, paru minut – i robi sie to raz.

Zaleta SVN jest natomiast to, ze wiesz, gdzie jest twoj firmowy kod. Nie ma sytuacji, ze komus padl dysk w laptopie i okazalo sie, ze nie masz Bardzo Istotnego Kawalka.

@trasz:

Wszystko to mozna zrobic tez z SVN – na czas rozwijania kodu robi sie po prostu oddzielnego brancha.

Wiem kilka komentarzy wyżej napisałem to samo niejakiemu pijaczkowi.

Sęk w tym, że radosne tworzenie branchy w systemie scentralizowanym jest jednak mniej elastyczne. Przykładowo A, B i C pracują nad jakąś funkcjonalnością na swoim wspólnym developerskim branchu X. Kawałek A jest względnie niezależny, ale kawałki ludzi B i C są ściśle powiązane i muszą oni się często ze sobą synchronizować, najlepiej tak, żeby nie utrudniać pracy A.

W środowisku scentralizowanym najbezpieczniej by było, gdyby A pracował na branchu X, a B i C zrobili sobie "podbranch" X_1.

W środowisku rozproszonym B i C mogą sobie pushować/pullować od siebie nawzajem do woli nie przeszkadzając A, a jak już się ich kod ustabilizuje to A od nich ciągnie.

Do tego w przypadku CVS (w SVN raczej nie ma tego problemu) trzeba zapewnić jakiś rozsądny schemat nazywania branchy, zwłaszcza jeśli się branchuje nie cały repozyt a tylko poszczególne moduły, bo inaczej ktoś sobie zrobi brancha X na module A, ktoś brancha X na module B (CVS nie zgłosi problemu, bo mu się nic nie konfliktuje), potem ktoś w całym repozycie zrobi cvs up -r X i dostanie więcej, niż by chciał.

Zaleta SVN jest natomiast to, ze wiesz, gdzie jest twoj firmowy kod. Nie ma sytuacji, ze komus padl dysk w laptopie i okazalo sie, ze nie masz Bardzo Istotnego Kawalka.

Z tym się po namyśle muszę zgodzić. Wprawdzie to wyróżnione centralne repozytorium będzie backupowane, ale zmiany, które sobie ludzie na boku pracowicie rzeźbią na swoich lokalnych branchach mogą zniknąć.

Jeśli nad danym kodem pracuje N osób synchronizujących się ze sobą to pół biedy, bo jak jednemu padnie, to N-1 osób ma w miarę aktualną kopię. Gorzej, jak nad czymś pracuje tylko jedna osoba commitująca tylko do swojego lokalnego repo. Wtedy pad dysku == duże ups.

Sęk w tym, że radosne tworzenie branchy w systemie scentralizowanym jest jednak mniej elastyczne.

Jak dla mnie jest to wystarczajaco elastyczne. W kodzie firmowym i tak nie robi sie zbyt wielu galezi bo kto bedzie tym pozniej zarzadzal/testowal/pisal specyfikacje/dokumentacje itp. Systemy scentralizowane sa proste i wymuszaja odrobine dyscypliny w projekcie (jak np. wstepne przetestowanie zmian przed wrzuceniem ich do repozytorium).

Co do zarzadzania wersjami w kopiach roboczych – nie wiem jak innym ale mnie to bardziej przeszkadza niz pomaga. Zmiany tam sa zbyt rozdrobnione i nieliniowe by vcs dawal cos wiecej niz zwykle "undo" w edytorze.

@oi:

bo kto bedzie tym pozniej zarzadzal/testowal/pisal specyfikacje/dokumentacje itp.

Ależ tu nie ma czym zarządzać/dokumentować — branch powstaje po to, żeby w czasie aktywnego developmentu nie destabilizować głównej ścieżki, a potem się go merge'uje do głownej i o nim zapomina.

wymuszaja odrobine dyscypliny w projekcie (jak np. wstepne przetestowanie zmian przed wrzuceniem ich do repozytorium)

Strzelam: nigdy nie robiłeś większych zmian. Większych, czyli takich, gdzie nad kodem pracuje kilka(naście) osób muszących się między sobą (niekoniecznie wszyscy — czasem jakieś mniejsze podzbiory) synchronizować.

Da się to rozwiązać wysyłając sobie patche, "podbranchami" albo mailami "uwaga, nie ciągnąć, bo przez kilka godzin będzie rozwalone, bo ja i Kazik się integrujemy", ale prościej zrobić pull od Kazika.

nie wiem jak innym ale mnie to bardziej przeszkadza niz pomaga. Zmiany tam sa zbyt rozdrobnione i nieliniowe by vcs dawal cos wiecej niz zwykle “undo” w edytorze.

Po prostu miałeś szczęście i robiłeś niezbyt duże zmiany.

Mnie akurat pomaga — ciągnę w tej chwili cztery częściowo kolidujące tematy, z których każdy się wiąże z grzebaniem w kilku-kilkudziesięciu plikach. "undo" to trochę za mało.

Oczywiście można mieć kilka kopii repozyta, ale przy rozmiarze projektu porównywalnym z kernelem Linuksa nie jest to już takie przyjemne.

Strzelam: nigdy nie robiłeś większych zmian. Większych, czyli takich, gdzie nad kodem pracuje kilka(naście) osób muszących się między sobą (niekoniecznie wszyscy — czasem jakieś mniejsze podzbiory) synchronizować.

Po pierwsze, zle strzelasz. Po drugie, narzedzia nie zastapia dobrego projektu i komunikacji. Jesli nad jednym kawalkiem kodu jednoczesnie pracuje kilkanascie osob to skonczy sie to katastrofa niezaleznie od uzytych narzedzi. Nawet najwiekszy projekt da sie podzielic na male dobrze zdefiniowane czesci. Ale nie robi sie tego ad hoc w trakcie kodowania, a wczesniej, na etapie projektu. Nie potrzeba nawet do tego wyszukanych narzedzi, wystarczy zwykly arkusz Excela.

@oi:

Po drugie, narzedzia nie zastapia dobrego projektu i komunikacji. Jesli nad jednym kawalkiem kodu jednoczesnie pracuje kilkanascie osob to skonczy sie to katastrofa niezaleznie od uzytych narzedzi.

Podział na moduły nie ma tu nic do rzeczy. Moduły zależą od siebie nawzajem. Mogą być dowolnie rozdrobnione, ale nigdy nie będą doskonale niezależne.

Interfejsy nigdy nie będą doskonale elastyczne i dopasowane do dokładnie wszystkich możliwych wymagań.

Kilkanaście osób pracuje nad całością, nie nad jednym plikiem/modułem.

Ale nie robi sie tego ad hoc w trakcie kodowania, a wczesniej, na etapie projektu.

To jest możliwe tylko w przypadku projektów "fire&forget", które się robi raz, praktycznie od zera, wypuszcza i potem już tylko ewentualnie poprawia w nich bugi.

W przypadku projektów, które żyją długo, pomiędzy wersjami dochodzą nowe funkcjonalności, zmieniają się wymagania (definiowane przez ustawodawców i organizacje tworzące standardy, nie przez klientów) często niezbędne są głębokie zmiany. Architektura w mniejszym lub większym stopniu się zmienia. Mimo, że projekt ma wyróżnioną fazę projektowania/przeprojektowywania to i tak potem trzeba te zmiany projektu wprowadzić w sposób, który zminimalizuje ryzyko rozwałki, a ponieważ moduły od siebie zależą, często poszczególni developerzy muszą się synchronizować między sobą na wzajem nie afektując reszty świata przynajmniej do czasu, kiedy ich zmiany są w miarę stabilne.

Przykład z mojego podwórka (projekt rozwijany od 8 lat, który przeszedł w międzyczasie kilka dużych refactoringów w miarę nabywania wiedzy z pola, zmian wymagań i dodawania nowych rzeczy pod kątem nowych rynków) — mamy zestaw wewnętrznych dobrze zdefiniowanych (wg wiedzy i założeń, jakie były dostępne na początku projektu kilka lat temu) interfejsów, przez które moduły ze sobą gadają. Jeden interfejs potrafi być implementowany przez 8-10 modułów, które w różnych kombinacjach są wykorzystywane przez różne podprojekty. Każdy z tych modułów ma od kilkuset do kilkunastu kilo linii kodu. Niektóre z tych modułów są absolutnie niezbędne, żeby cokolwiek móc testować.

I teraz przychodzi konieczność dodania nowego ficzera, który wymaga dość sporego przeorania tego API.

Uwierz mi, że praca nad tym przy pomocy scentralizowanego vcsa to spory ból w tyłku. Kończy się na wysyłaniu sobie wzajemnie patchy i ręcznego nimi zarządzania, żeby móc się zgrać z ludźmi, których moduły zależą od mojego, żebyśmy mogli wrzucić nasze zmiany wrzucić hurtem i nie rozwalić innym repozytorium.

Da się? Da. Czy jest to wygodne? Ani trochę.

Git-gui, IMO, jest do bani. Ale gitk to najlepszy przegląd historii jaki widziałem w gui dla VCS-ów.