Kwi 12 2009
git
Wreszcie udało mi się zebrać i zrobić wpis nt. git'a. Pewnie pojawią się w nim rzeczy wspólne dla innych rozproszonych systemów kontroli wersji i powinienem ten wpis zatytułować "Rozproszone systemy kontroli wersji na przykładzie git'a", jednak samo "git" się pisze krócej, lepiej wpada ludziom w ucho oraz nikt nie będzie marudził, że w X jest to samo a w Y jest troszeczkę inaczej a w Z to w ogóle kosmos (nie korzystam z X, Y, Z, korzystam tylko z gita, kropa). Nie chciałbym też, aby doszło do flame'u nt. wyższości gita nad mercurialem czy czegoś podobnego. To i to jest rozproszone, to i to ma zalety, każdy używa tego co jest dla niego wygodniejsze. Aczkolwiek jakby ktoś chciał powjeżdzać na centralne systemy kontroli wersji, nie musi się hamować (tylko bez mięska).
Sam osobiście korzystałem z SVN'a przez rok, pracując jako programista PHP. Uważam SVN'a za jedno z najbardziej bezużytecznych i bezsensownych narzędzi programistycznych z jakim kiedykolwiek się spotkałem. Szczytem mojej nienawiści były wakacje, kiedy wróciłem do domu, gdzie Internet jest dostarczany po WiFi, przez co upload jest po prostu tragiczny. Zrezygnowałem z SVN'a, przy okazji kończąć z pracą w PHP. Projekty uczelniane nie były aż tak wymagające więc nie musiałem mieć do nich żadnego systemu kontroli wersji. Jednak jakiś czas później kupiłem sobie laptopa, a chcąc w łatwy sposób przenosić projekty z komputera stacjonarnego na laptopa i w drugą stronę musiałem się uzbroić w odpowiednie do tego narzędzie. Wszelkiego rodzaju scp czy ftp odpadają z miejsca jako nieporęczne i z brakiem możliwości rozwijania projektu na dwóch maszynach na raz. Systemy centralne wymagają serwera centralnego. Żadna z moich maszyn nie chodzi 24/7, więc się nie nadają. Z zewnętrznymi jest problem z przepustowością łącza oraz ilością miejsca na serwerze. Pozostało się zapoznać z tym co oferują systemy rozproszone.
Do wyboru (z tych znanych) były 3. Bazaar, git i Mercurial. Bazaar odpada z miejsca, ze względu na producenta. Mercurial odpadł z powodu pythona (raz że nie potrzebuję przenośności, a dwa nie mam zaufania do tego typu języków wykorzystywanych w wypadku normalnych aplikacji). Więc został git. Szybki przegląd dostępnych serwisów udostępniających hosting. Na początku wybrałem assemblę, ale w tej chwili przenoszę się na github'a. Może ma mniej ficzerów, ale jako sam hosting, moim zdaniem, nadaje się znacznie lepiej. Jeszcze słowem wyjaśnienia: z gitem możemy pracować jak z SVN'em lub jak z systemem rozproszonym. Opiszę tę drugą drogę, ponieważ sam z niej korzystam i uważam, że jest znacznie lepsza.
Przez długi czas jako system kontroli wersji do kernela był używany BitKeeper, który jest produktem komercyjnym i zamkniętym, jednak pozwalał na darmowe wykorzystywanie do projektów Open Source. Jednak fanatycy Free Software nie mogli się z tym pogodzić, przez co wybuchały kłótnie, że to świętokradzctwo (nie ma to jak religijni fanatycy). Później Linus i Larry McVoy (CEO BitMover, firmy która zrobiła BitKeepera) doszli do wniosku, że będzie lepiej jeżeli drogi Linuksa i BitKeepera się rozejdą. Linus postanowił że nie ruszy kodu Linuksa póki nie będzie miał zastępstwa dla BitKeepera, jednak nic nie spełniało jego oczekiwań, więc zaczął się zastanawiać czy uda mu się napisać własny system zarządzania wersjami w 2 tygodnie. I na szczęście się udało. Aktualnie gitem zajmuje się Junio Hamano.
W rozproszonych systemach kontroli wersji nie mamy centralnego serwera (jest tylko serwer który udostępnia kod dla użytkowników, najczęściej push'ować na niego może tylko lider projektu) oraz Twój kod jest trzymany w wielu miejscach na raz (co zwiększa bezpieczeństwo, bo nawet jeżeli rozwalisz swoją maszynę to zawsze możesz ściągnąć swoją pracę od kogoś innego). Cały kod przemieszcza się między deweloperami na zasadach p2p. Oznacza to tyle, że w całej tej sieci żadne miejsce nie ważniejsze od jakiegokolwiek innego miejsca. Przekłada się to również na to, że repozytorium tak na prawdę znajduje się na Twoim dysku. Nie trzeba odpalać żadnego serwera czy posiadać połączenia z internetem żeby pracować nad kodem. Jest to bardzo szybkie (tak samo jak szybsze jest przekopiowanie iso DVD Debiana z dysku na dysk, niż ściągnięcie go z głównego ftp'a) oraz bardzo pomocne w przypadku gdy chcemy pracować gdzieś gdzie nie ma internetu.
Co ważniejszego, każde repozytorium jest oddzielną gałęzią całej sieci. Nie trzeba się tym przejmować, to po prostu istnieje. W git'cie gałęzie są tak łatwe i przyjemne w zarządzaniu, że grzechem jest nie mieć ich kilku. Nawet jeżeli nie jesteś do tego przekonany teraz, to kiedy zrobisz swoją pierwszą gałąź i zobaczysz jakie to fajne, zechcesz mieć ich wiecej.
W przeciwieństwie do centralnych systemów, Twoje gałęzie są prywatne i możesz mieć ich tyle ile chcesz i nazwane tak jak chcesz. Nie występują sytuacje w których nie możesz nazwać w dany sposób Twojej gałęzi, bo ktoś inny nazwał już tak swoją.
SVN przez pewien czas chwalił się że tworzenie gałęzi w ich systemie jest bardzo tanie i szybkie. Ale kogo tak na prawdę to ochodzi? Nie problemem jest stworzenie taniej i szybkiej gałęzi (git do stworzenia gałęzi potrzebuje kilkudziecięsiu bajtów - jak szybkie to może być?), problem jest szybkie łączenie ich. I git na prawdę to potrafi.
Nawet jeżeli występują konflikty jest bardzo łatwo je rozwiązać. Tym łatwiej im jesteś ważniejszy w projekcie. Jeżeli ściągasz od dwóch różnych osób kod i przy drugiej wystąpi konflikt, zawsze możesz wystawić swój kod połączony z kodem pierwszej osoby i napisać do drugiej, żeby zaaktualizowała sobie Twoją gałąź i rozwiązała konflikty. Zawsze możesz zrobić to Ty, ale jeżeli nie jest to część projektu którą Ty się zajmujesz tamta osoba zrobi to szybciej, efektywniej i lepiej niż ktokolwiek inny. I oto właśnie chodzi. Zrobią całą brudną robotę za Ciebie!
Kolejną świetną rzeczą którą lubię w rozproszonych systemach jest "sieć zaufania". Nie masz centralnego serwera więc to czy czyjś kod przejdzie dalej czy nie odbywa się na zasadzie zaufania do tej osoby. Jeżeli jej nie znasz to sprawdzisz co jej kod oferuje, jeżeli ją znasz i jej ufasz po prostu ściągniesz jej kod i połączysz ze swoim. Odpada problem wybrania grupy osób która powinna mieć dostęp do centralnego serwera. Zrobisz tę grupę za małą? Źle, bo robisz problem dla ludzi którzy piszą coś na prawdę wartościowego. Zrobisz za dużą? Masz w projekcie kretynów z którymi normalnie byś nie chciał pracować.
Dzięki sieci zaufanych ludzi nie musisz także wiedzieć o setkach różnych gałęzi. Wiesz o kilku Twoich zaufanych współpracowników. Oni wiedzą o kilku innych, itd. Zbierasz cały wartościowy kod współpracując bezpośrednio tylko z kilkoma ludźmi. I nie jest to coś nowego. W taki sposób myślimy i działamy od zawsze. Prace domowe nie ściąga się od matołów którzy niewiele potrafią tylko od ludzi, codo których mamy pewność, że zrobili ją dobrze.
Rzeczą która odróżnia gita od innych systemów jest to, że git nie patrzy na repozytorium pod kątem plików. Git nie widzi poszczególnych plików, on widzi tylko całe repozytorium. Przez co, nie możesz pobrać jednego pliku z całego repozytorium. Za to pobranie całości i złączenie tego jest znacznie szybsze niż gdziekolwiek indziej, przez to, że git operuje na wielu plikach na raz. Problem zaczyna się wtedy kiedy masz na prawdę wielkie repozytorium, gdyż przy pierwszym pobraniu musisz ściągnąć całe. Rozwiązać to można poprzez tworzenie małych repozytoriów z częściami projektu i jednego superrepozytorium które zawiera dowiązania do mniejszych.
Więc... z mojej strony to wszystko (przepraszam tych zawiedzonych którzy liczyli na tutorial, jeżeli będą chętni do przeczytania takiego czegoś mogę go napisać później). Jeżeli macie pytanie lub chcecie pomarudzić na centralne systemy, nie krępujcie się.
12 Kwi 2009, 00:50:08
Świetny tekst. Czegoś takiego właśnie potrzebowałem odnośnie rozproszonych systemów kontroli wersji (ciągle siedzę w centralnych). Polecisz jakieś sensowne materiały by wgłębić się w git-a?
12 Kwi 2009, 00:52:28
Tę, k*wa, tę!
12 Kwi 2009, 00:59:28
@pascon: dział dokumentacji na stronie git'a (http://git-scm.com/documentation) - dużo i treściwie acz po angielsku. Z polskojęzycznego polecam blog randomseed (http://randomseed.pl/) są tam 3 ciekawe wpisy jak używać git'a, gdzieś chyba były jeszcze 2 blogi które opisywały git'a po polsku, ale niestety nie mam adresów. Jak wpiszesz w google "git" to powinieneś je znaleźć.
@Górny: przestań się pieklić człowieku, jak zrobiłem byka to jak człowiek weź napisz gdzie dokładnie, to zaraz poprawię (i jeszcze podziękuję za zwrócenie uwagi), a tymi swoimi wyskokami to co najwyżej możesz do swoich rodziców tak gadać.
12 Kwi 2009, 01:01:26
Matthew: Wszędzie zrobiłeś. Każde zastosowane przez ciebie „tą” jest niedopuszczalne.
12 Kwi 2009, 02:24:05
M.G - z wyjątkiem "tą górną", to było dobrze akurat (chyba) :P
12 Kwi 2009, 02:43:34
excerpt...
12 Kwi 2009, 02:56:00
A w ogóle to dobry i przyjemny tekst. Ja sam używam gita, ale w trochę nieprawidłowy sposób, bo mam repo na cały folder z projektami, ale nie opłaca mi się zakładać po jednym repo na projekt. (No, ale pracę inżynierską trzymam już oddzielnie)
12 Kwi 2009, 09:33:49
Nie bardzo sobie wyobrażam jak się pracuje w systemach rozproszonych. Przecież 5 osób może w tym samym czasie robić to samo nawet o sobie nie wiedząc. W systemie centralnym leci commit na serwer, serwer rozsyła commit loga na listę mailową i wszyscy wiedzą na czym stoją.
12 Kwi 2009, 11:40:09
Całkiem przyjemne streszczenie wykładu Linusa o git dla pracowników Google:
http://www.youtube.com/watch?v=4XpnKHJAok8
12 Kwi 2009, 12:08:07
@trójkąt: Nie widzę jak w SVN nie da się robić tego samego. Od czegoś jest organizacja pracy i przydzielanie zadań, prawda?
12 Kwi 2009, 12:31:02
No ale powiedzmy, że pracuję w grupie 7 osobowej. Bez wydzielonego zdalnego repozytorium jedyną metodą żeby pozostali dostali mój nowy commit jest pushowanie do każdej osoby lub poinformowanie ich aby pullowali ode mnie. Dobrze myślę?
12 Kwi 2009, 13:16:47
tak z czystej ciekawosci,co masz do producenta bazaara?(sorry za brak pliterek)
12 Kwi 2009, 14:27:58
@trójkąt: Nie pracowałem nigdy w dużym projekcie z użyciem gita, używałem go tylko do własnych, małych potrzeb. Ale o ile dobrze rozumiem, działa to na tej zasadzie że każda grupa ludzi pracująca nad daną częścią projektu ma rodzaj głównego repo do którego pushują członkowie grupy, z którego np. szef grupy pushuje do głównego repo projektu. O ile rozumiem, różnica jest taka że lokalna kopia to jest również repozytorium - więc commity robisz lokalnie, i jak uznasz że dane zadanie ukończyłeś, pushujesz do mastera. W svn commity lecą od razu do mastera. Wychodzi na to że Git jest bardzo elastyczny, możesz z nim pracować podobnie do tego jak robisz z svn, ale jest to marnotrawstwo jego możliwości (niech ktoś mnie poprawi jeśli się mylę).
12 Kwi 2009, 14:40:10
Właśnie, czyli i tak w większości przypadków pracuje się na jakieś wersji modelu scentralizowanego, tyle że systemy rozproszone oferują większą elastyczność maszynom klienckim czyli lokalne commity, wymianę commitów pomiędzy klientami, lokalne branche itp.
Testowałem ostatnio Bazaara pracującego właśnie w modelu scentralizowanym ale brakowało mi jednej niezbędnej dla mnie rzeczy jaką są zdarzenia po stronie serwera (dopiero planują wprowadzenie tego) np. po dodaniu commita. Czy GIT coś takiego oferuje?
12 Kwi 2009, 16:01:47
@zen: po prostu uważam, że robią beznadziejne distro (nigdy nie gościło u mnie dłużej niż 48 godzin, bo zawsze się coś waliło) i nie jestem się w stanie przekonać, że zrobili coś dobrze. A nawet jak Bazaar jest dobry to i tak pozostaje kwestia tego, że jest napisany w pythonie.
@trójkąt:
1. W rozproszonym się nie pushuje, tylko pulluje. Pushuje tylko lider projektu do oficjalnego repo (skąd ściągają projekt zwykli userzy). Oprócz tego robi się "gałęzie" na serwerze które trzymają publiczne gałęzie deweloperów (polecam przejrzeć http://git.kernel.org/). Nie jest to zasada i jeżeli masz swój komputer włączony 24/7 czy własny serwer to możesz na nim trzymać. Git wspiera 4 rożne protokoły (ssh, git, http i coś jeszcze) więc udostępnienie repozytorium na zewnątrz nie jest problemem. Co do komunikacji to się najczęściej używa list mailingowych. Wiem, że może się to wydawać straszne, ale używają tego przy robieniu kernela i jakimś cudem zdaje to egzamin (Linus nie marnowałby czasu na coś co słabo działa). Co do zdarzeń po stronie serwera. Sam takiego czegoś nie używam, ale widziałem skrypty w folderze .git które się wykonują w różnych przypadkach, więc prawdopodobnie da się to zapędzić to wysyłania e-maili czy czegoś podobnego. Nie wiem, nie potrzebowałem, nie korzystałem. Dodatkowo w repo Debiana jest dodatek do git'a który pozwala na wysyłanie patchy (w przypadku jakbyś chciał korzystać z git'a a główny projekt korzystał z czegoś innego).
12 Kwi 2009, 16:13:43
Wiecie - Git może pracować w sposób scentralizowany, a SVN w sposób zdecentralizowany ;] Co nie znaczy, że robią to dobrze.
Należy pamiętać, iż wybór narzędzia nie powinien się opierać na argumentacji pokroju "bo to jest zdecentralizowane, dude!". Wszystko zależy od potrzeb, jakie dane środowisko programistów posiada. Od tego głównie zależy wybór scentralizowanych, czy też rozproszonych systemów kontroli wersji.
Druga sprawa to wybór samego narzędzia z danej kategorii. Łatwość obsługi, przyzwyczajenia programistów, wsparcie ze strony innych narzędzi, przenośność, czy też obecność GUI to niektóre z czynników.
Matthew, tekst dobry, ale dotyczący jedynie wąskiej problematyki. Podałbyś jeszcze odnośniki do stron pokroju http://www.whygitisbetterthanx.com/ ;]
Ja ze swojej strony przyznam, iż do większości grupowych projektów studenckich wykorzystuję SVN-a (GUI, wielosystemowość, przyzwyczajenie grupy itp.), a we własnym zakresie wykorzystuję Mercuriala i Gita (jeden i drugi jest bardzo przyjemny, przy czym pierwszy lepiej wspierany).
12 Kwi 2009, 16:15:04
PS. Ten szablon trzeba jeszcze dopracować ;] Za wąskie komentarze i zbyt gruba czcionka w treści.
12 Kwi 2009, 20:30:50
>Systemy centralne wymagają serwera centralnego. Żadna z moich maszyn nie chodzi 24/7, więc się nie nadają.
>Oprócz tego robi się "gałęzie" na serwerze które trzymają publiczne gałęzie deweloperów
@Matthew: czyli jednak centralna wersja kodu jest niezbędna do pracy w większej grupie. Użyłeś argumentu, że systemy centralne są fuj bo nie zawsze masz dostęp do internetu lub jakość łącza jest słaba. Ale przecież w systemie rozproszonym żeby pullować od kogoś zmiany to nie tylko Ty musisz mieć dostęp do internetu ale jeszcze w tym samym czasie dostępny musi być komputer osoby, od której chcesz pobrać zmiany (współczynnik problemów x2). Dodaj jeszcze 3 osoby, które zrobiły ostatnio coś ciekawego i przydało by się pullować od nich i już robi się ciepło.
12 Kwi 2009, 20:44:42
@trójkąt: masz rację i nie masz racji. Z systemami centralnymi _zawsze_ musisz mieć centralny serwer. W systemie rozproszonym nie. Patrz na to przez pryzmat robienia małego projektu na własne potrzeby. Robisz go na stacjonarnym, jedziesz na święta do domu, ale chcesz coś po drodze zrobić, bo długo jedziesz pociągiem, to klonujesz repozytorium na laptopa i dalej pracujesz. Nie musisz zakładać kont, nie musisz płacić za hosting, a nawet jak hosting jest darmowy, to przecież nie musisz chcieć żeby każdy widział co robisz. I git Ci to daje.
I że jeżeli chcesz pullować od innych osób, tak gdzieś muszą trzymać swoje repozytoria i te komputery muszą być dostępne w sieci. Ale z centralnym jest to samo, ten komputer też musi być dostępny w sieci. Dlatego dobrym zwyczajem jest to co widać na git.kernel.org. Deweloperzy mają tam własne miejsce na gałęzie repozytoriów (w ten sam sposób działą github). Mógłbyś zapytać "ale czym to się różni od centralnego?". Wieloma rzeczami. Repozytoria tak na prawdę są lokalnie, ten pseudo-centralny to może być zwykły serwer www, który robi tylko jako takie ogólne archiwum, żeby nie trzeba było pamiętać miliona adresów różnych deweloperów (userzy którzy chcą ściągnąć gotowy projekt też muszą mieć jeden adres skąd to pobrać). Dodatkowo każdy z tych deweloperów trzyma Twoją niezmienioną kopię kodu (nie wspomniałem o tym, ale ze znanych mi systemów tylko git, mercurial i monotone (może bazaar, ale pewny nie jestem) gwarantują, że to co wyciągniesz z repo jest tym co do niego włożyłęś). Możesz pracować bez podłączenia do sieci. Jest to również znacznie szybsze. Nie musisz ciągle przesyłać czegoś przez sieć, tylko commitujesz to lokalnie.
Nie popadajmy w skrajności w skrajność. Da się pracować w systemie całkowicie rozproszonym, ale nawet dla samych ludzi jest to niezbyt wygodne. A nawet jeżeli spróbujesz pracować na git'cie w stylu SVN'a to i tak nadal jest to znacznie wygodniejsze niż praca na normalnym SVN'ie.
12 Kwi 2009, 21:36:32
Dobry tekst! Przekonałeś mnie, abym spróbował Gita. :)
12 Kwi 2009, 21:39:13
Eee... Nie ma tutaj żadnych zwolenników Mercuriala, czy też Bazaara?
Nie przyjdzie nikt i nie powie "ale Mercurial jest przenośny i wspierany przez różniaste narzędzia"? :D
12 Kwi 2009, 21:40:28
Zal: Fakt, teraz by się przydało przeczytać coś podobnego o Mercurialu i Bazaar.
12 Kwi 2009, 21:41:36
niech Ci będzie Zal... szkoda, żen ie ma TortoisGIT :P (chociaż coś jest na google code, ale nie widziałem żadnych opinii o tym programie)
btw: może ktoś w skrócie wytłumaczyć czym różni się pull od fetch?
12 Kwi 2009, 21:43:00
@Walker: Przyznam, że materiałów na ten temat jest sporo, ale nie zawsze są wiarygodne. Szczególnie, że większość osób pisze coś w stylu "używam XXX i jest świetny!". Po drugie - wszystko zależy od tego pod jakim kątem porównania się dokonuje i na czym zależy developerowi.
@Airborn: :D
12 Kwi 2009, 21:43:22
@Zal: zrobiłem mały zabieg żeby tego ne było (patrz pierwszy akapit). Git też ma swoją implementację na Windows, ale nie działa ona tak szybko jak na Linuksie (raczej wina Windowsa). Poza tym są pluginy do różnych IDE (na pewno do NetBeans, do Eclipse pewnie też) które dodają wsparcie dla gita.
A poza tym... nie piszę i nie mam zamiaru pisać aplikacji dla czegoś innego niż Linux, więc nie jest mi potrzebna przenośność (jak Linus powiedział "Przenośność jest potrzebna dla ludzi, którzy nie potrafią pisać nowych programów").
@Airborn: pull (w skrócie) to fetch + merge.
12 Kwi 2009, 21:45:09
czyli żeby być 'up to date', z np repozytorium na githubie to powinienem był z niego robić pull, czy fetch + merge:>
12 Kwi 2009, 21:45:20
@Matthew: Nie piszę o Tobie tylko o zastosowaniu danego rozwiązania w ogólności ;] Ciebie to bym nawet nie próbował do niczego zmusić :D Równie dobrze mógłbym dyskutować z Ziemią, jako taką, o możliwości zmiany kierunku jej ruchu obrotowego ;p
12 Kwi 2009, 21:57:15
@Airborn: zależy czego akurat potrzebujesz. pull bez pytania połączy Ci obie gałęzie. Fetch najpierw zaaktualizuje zdalną gałąź (jeżeli masz jej kopię u siebie) a dopiero później przy pomocy merge połączy. Pierwsze jest przydatne w przypadku osób którym ufasz co do projektu i głównej gałęzi repozytorium, a drugie w przypadku nowych osób oraz jak z jakiegoś powodu chcesz mieć aktualną gałąź u siebie, ale nie chcesz jej jeszcze łączyć (np. wiesz, że na pewno będzie konflikt a jeszcze nie skończyłeś swojej pracy i chcesz ją dokończyć a dopiero później rozwiązać konflikty).
@Zal: a na to też są dwa fajne cytaty Linusa:
1. "If you still don't like it, that's ok: that's why I'm boss. I simply know better than you do."
2. "Which mindset is right? Mine, of course. People who disagree with me are by definition crazy. (Until I change my mind, when they can suddenly become upstanding citizens. I'm flexible, and not black-and-white.)"
13 Kwi 2009, 09:22:51
Zal: Jeśli porównać z SVN (z innymi nei miałem styczności), to Git jest po prostu lepszy we wszystkim. Jak chcesz konkrety, to napisz co Cię wkurza w SVN.
Airborn: Jest TortoiseGit i działa bardzo dobrze. Znaczy, na tyle dobrze, na ile coś może działać na Windowsie.
Matthew: Z różnicy między pull a fetch + merge to jeszcze jest jedna - pull zrobi Ci merge jedynie na tej gałęzi, na której aktualnie pracujesz.
13 Kwi 2009, 11:38:00
@sharnik: Zależałoby mi bardziej na porównaniu możliwości systemów zdecentralizowanych - "wielkiej trójki".
Z tego, co się orientuję to zarówno Git, jak i Bazaar oraz Mercurial są lepsze od SVN-a pod niemal każdym względem. Przy czym sam SVN też posiada coś czym przewyższa systemy zdecentralizowane - wsparcie ze strony innego oprogramowania.
13 Kwi 2009, 11:48:24
Któryś ze zdecentralizowanych SCM-ów pozwala pobrać jedynie najświeższe wydanie (z możliwością dalszego aktualizowania) bez konieczności pobierania całej historii?
13 Kwi 2009, 14:47:49
@Zal: dla ścisłości, nie SVN _ma_ wsparcie, ale ktoś w programach zrobił wsparcie _do_ SVN'a. W tej chwili, chyba każde, Linuksowe IDE posiada wsparcie dla git'a (czy to wtyczki, czy wbudowane). A jak nie ma, to o to chodzi w Open Source, że możesz sam sobie do niego wsparcie napisać. ;] A nawet jak coś w tej chwili nie ma wsparcia dla czegoś, to nie wiesz czy za miesiąc tego wsparcia mieć nie będzie. Nie ma sensu używać czegoś gorszego tylko dlatego że w tej chwili coś innego nie wspiera czegoś lepszego. Poza tym żaden frontend nigdy nie da Ci takich możliwości jak obsługa git'a z konsoli.
@Górny: nie znalazłem czegoś takiego w git'cie (może po prostu coś przeoczyłem). Ale takie działanie wypacza sens rozproszonych systemów. Wtedy byśmy się cofali do ery CVS, gdzie nie możemy merge'ować gałęzi bez koszmarnych konfliktów. Nie traktujmy klientów systemów rozproszonych tylko jako narzędzi do ściągania świeżego kodu, lecz jako narzędzi które pomagają rozwijać ten kod.
13 Kwi 2009, 15:17:30
Matthew: Ale przecież rozwijasz *bieżący* kod. Jeśli masz mergować czyiś bieżący kod, to co za różnica, czy ten ktoś, co było rok temu, czy nie?
13 Kwi 2009, 15:23:19
@Michał Górny: Nie można patrzeć w przyszłość nie znając przeszłości ;)
Historia jest potrzebna chcesz sprawdzić kto jest odpowiedzialny za dany fragment kodu, albo sprawdzić od kiedy występuje dany bug. Przykłady można by mnożyć.
13 Kwi 2009, 17:14:55
@Matthew: Nie do końca mnie zrozumiałeś. Po pierwsze:
"sam SVN [...] posiada [...] wsparcie ze strony innego oprogramowania."
To było wystarczające. Przynajmniej tak sądziłem.
Po drugie - ja piszę w ogółach i o obecnym stanie. Nie uwzględniam tego, iż za rok dane rozwiązanie będzie wspierane nawet przez lodówki. Obecnie tak nie jest i na tym opiera się m.in. użytkownik dokonujący teraz wyboru. Może mu przyjdzie zmienić zdanie, któż to wie? ;]
13 Kwi 2009, 20:15:56
@Zal: Ja akurat dobrze Cie zrozumiałem, chcę tylko zwrócić uwagę na inną rzecz. Wybór SVN czy git nie może się opierać na tym czy coś jest wspierane przez dane oprogramowanie czy nie. Co innego system operacyjny, ale wtedy to się sprowadza do wyboru SVN czy Mercurial. Oprogramowanie można zmienić. A podejście "zostanę przy tym badziewiu jakim jest SVN bo X ma w sobie wsparcie dla niego" jest czystą głupotą. Gdyby każdy deweloper tak myślał to nadal byśmy siedzieli w erze CVS'a, bo jak może napisać wsparcie dla SVN'a skoro się z niego nie korzysta, bo nie ma wsparcia w obecnym oprogramowaniu.
W skrócie: nie lubię jak ktoś mi przytacza debilne argumenty, które totalnie nic nie znaczą, ale robią fajną politykę. Ludzie powinni dąrzyć do maksymalnego i efektywnego wykorzystania narzędzi, a nie iść na łatwiznę. Jak Eistain powiedział "Wszystko powinno być tak proste jak to tylko możliwe, ale nie prostsze".
13 Kwi 2009, 20:19:57
@Matthew: Pojechałeś z debilną argumentacją. W ogóle nie uwzględniasz czynnika ludzkiego, a to jest błąd. Nie piszemy jedynie o Tobie, czy o mnie - piszemy o wszystkich.
A co do CVS-a - czyżbyś nie wiedział, iż do tej pory w wielu firmach jest używany? ;>
13 Kwi 2009, 20:22:56
@Zal: osoba która nie chce trochę poklepać w konsoli tylko dlatego, że musi klepać w konsoli zamiast wyklikać sobie to w okienku (i wybrać lepsze narzędzie w miejsce znacznie gorszego) nie powinna być deweloperem. W końcu ona zarabia na życie klepaniem w klawiaturę. Weź przykład z Japonii, tam nie idzie się na łatwiznę, tam się promuje ludzi którzy coś potrafią i nie są leniwi.
13 Kwi 2009, 20:27:09
@Matthew: Jak jest, a jak być powinno to dwie różne rzeczy. Nie idealizuj i nie wpadaj w błąd "wszyscy myślą tak, jak ja" ;]
Powtórzę kolejny raz - nie bagatelizuj czynnika ludzkiego. Od tego ostatniego naprawdę wiele zależy. I to widać chociażby po popularności systemów operacyjnych (Git w parze z Windowsem?).
13 Kwi 2009, 20:33:52
@Zal: ale jak powinno być jest ważniejsze. To, że ktoś strzela do kogoś tylko dlatego że ma broń i nierówno pod sufitem nie znaczy, że teraz wyrzucamy do kosza to jak powinno być, czyli nie dajemy debilom broni.
Ci ludzie to stado owiec którymi jak dobrze pokierujesz to zrobią co chcesz. Więc lepiej ich pokierować na rozwiązanie lepsze niż wciskać im gorsze tylko dlatego, ze można na tym zarobić kasę (jak wciskanie ludziom Windowsa, jak nie mają co robić z kasą to niech przynajmniej Mac'a kupią).
A to, że git nie działa tak cudnie na Windzie jak na Linuksie... no cóż, jak winda jest beznadziejna to nic nie zrobisz, na szczęście jest wolny wybór, świat się zmienia i nie trzeba się ograniczać do jednego gównianego systemu.
13 Kwi 2009, 20:42:24
@Matthew: I dlatego uważam, że jeżeli już developerzy (i menadżerowie) uznają, iż chcą przejść na rozproszone systemy kontroli wersji (co jest korzystne) to prędzej zastanowią się nad Mercurialem, niż nad Gitem. Chociażby ze względu na lepsze wsparcie oraz przenośność (wyobrażasz już sobie tych programistów siedzących przed Visual Studio?). Mercurial zyska większą popularność chyba, że sam Git zmieni kierunek rozwoju (w co wątpię).
Co nie zmienia faktu, że w kategorii Linux Git będzie radził sobie znacznie lepiej.
13 Kwi 2009, 20:47:51
@Zal: nie przeżyłbyś nie wspominając o Mercurialu, prawda? ;>
Jak zaznaczyłem w pierwszym akapicie. Piszę o gitcie bo gita używam, ale masa rzeczy jest wspólnych (szczególnie w gitcie i Mercurialu). Nawet jeżeli na Windzie będzie królował Mercurial, nie obchodzi mnie to. Póki nie zginie to badziewie znawe SVN'em nie przestanę mówić, że git jest lepszy (ale nie dlatego, że jest on lepszy z decentralizowanych (chociaż tak jest), ale dlatego, że zdecentralizowany git jest lepszy od scentralizowanego SVN'a). Pomijając fakt, że mam nadzieję, że ten system niedługo umrze, albo zrobią z niego Uniksa.
13 Kwi 2009, 20:55:33
@Matthew: Podejrzewam, że migracja na rozproszone systemy będzie jeszcze trochę trwać. I nie wykluczone, że nawet w "thinktankach" coś się ruszy.
Co do Mercuriala - tak, musiałem wspomnieć ;] Z racji korzeni Gita podejrzewam, iż nie będzie on nakierowany na świat developerów, jako taki, lecz jedynie na developerów pracujących pod Linem (m.in. dev Javy/Pythona/Rubiego i aplikacji pod Lina). Mercurial z założenia jest tworzony dla szerszej grupy.
14 Kwi 2009, 09:22:35
Jeszcze jedno: to tylko w Mercurialu tak jest, czy w GIT-cie też przy mergowaniu czyiś zmian nie daje się żadnego opisu, co to było?
15 Kwi 2009, 15:03:50
"SVN przez pewien czas chwalił się że tworzenie gałęzi w ich systemie jest bardzo tanie i szybkie. Ale kogo tak na prawdę to obchodzi?"
Obchodzi ludzi, którzy rozważają migrację z CVS (tak, CVS ciągle żyje). Poza tym specyficzne zalety git-a są cenne tylko w specyficznych zastosowaniach.
Firma, której serwery mają uptime 99,873% nie będzie w ogóle zainteresowana pracą offline. Przy pracy intensywnie zespołowej robienie sobie prywatnego brancha i trzymanie go poza centralnym serwerem będzie wręcz "bad practice", bo utrudni ciągłą wymianę informacji i audytowanie/integrację kodu na bieżąco.
Poza tym inna sprawa -- pozyskiwanie kadry. Znajomością CVS/SVN chwali się przynajmniej 90% koderów, z git-em jest dużo gorzej. No i integracja z IDE/RAD-ami (której brakuje).
No i IP: są firmy, z których kodu nie możesz wynieść z siedziby firmy nawet na firmowym laptopie, a jedyny sposób pracy zdalnej to VPN+remote desktop. Standard w np. bankach.
Git rozwiązuje problemy charakterystyczne głównie dla projektów Open Source. Rozproszenie jest fajowe, ale większość komercyjnych projektów ma jasno zdefiniowaną strukturę. Projekty i zadania są planowane, przypisywane, estymowane, mają deadline'y. Ludzie są dzieleni na streamy/zespoły, zasoby ludzkie są dokładnie znane. To się przekłada na sposób rozwoju kodu, a to z kolei na wymagania stawiane VCS-owi. Git nie ma tu do zaoferowania niczego na tyle cennego, by zrównoważyć koszt migracji.
15 Kwi 2009, 17:03:01
@Michał Górny:
git help merge
--no-commit
Perform the merge but pretend the merge failed and do not autocommit, to give the user a chance to inspect and further tweak the merge
result before committing.
-m <msg>
The commit message to be used for the merge commit (in case it is created). The git-fmt-merge-msg script can be used to give a good
default for automated git-merge invocations.
16 Kwi 2009, 01:00:38
> Obchodzi ludzi, którzy rozważają migrację z CVS (tak, CVS ciągle żyje).
Git tworzy brach szybciej niż SVN, również szybciej i lepiej je łączy. Poza tym po co komu branche skoro nie można ich łatwo połączyć.
> Poza tym specyficzne zalety git-a są cenne tylko w specyficznych zastosowaniach.
To git ma jakieś specyficzne zalety, które powodują że git nie jest przydatny dla nie-specyficznych zastosowań?
> Firma, której serwery mają uptime 99,873% nie będzie w ogóle zainteresowana pracą offline.
Nie, póki im serwery nie padną, tudzież z jakiegoś magicznego powodu deweloper będzie musiał pracować bez dostępu do sieci.
> Przy pracy intensywnie zespołowej robienie sobie prywatnego brancha i trzymanie go poza centralnym serwerem będzie wręcz "bad practice", bo utrudni ciągłą wymianę informacji i audytowanie/integrację kodu na bieżąco.
Ja bym powiedział, że rozproszenie akurat lepiej wspiera wymianę informacji i integrację kodu na bierząco. To, że branch jest lokalnie nie znaczy że nie można go wypchnąć na zewnątrz. Jeżeli tworzysz jakąś klasę, to nie zbiega Ci się na raz 10 deweloperów do kodzenia jednej metody. Bo by oszaleli jakby teraz mieli zacząć pracować w edytorach które wspomagają pisanie jednego dokumentu przez wielu użytkowników na raz.
> Poza tym inna sprawa -- pozyskiwanie kadry. Znajomością CVS/SVN chwali się przynajmniej 90% koderów, z git-em jest dużo gorzej.
Racja, mamy stado baranów to lepiej się nimi zatroszczyć niż zmusić ich do nauki. Ciekawe co by na studiach o tym powiedzieli "Panie, 90% studentów tego nie zdało, nie męczmy ich tym nigdy więcej, mimo że to podstawa tego kierunku"
> No i integracja z IDE/RAD-ami (której brakuje).
Pokaż mi linuksowe IDE/RAD które nie wspiera git'a.
> No i IP: są firmy, z których kodu nie możesz wynieść z siedziby firmy nawet na firmowym laptopie, a jedyny sposób pracy zdalnej to VPN+remote desktop. Standard w np. bankach.
Nadal nie jest to argument świadczący przeciw rozproszeniu.
> Git rozwiązuje problemy charakterystyczne głównie dla projektów Open Source. Rozproszenie jest fajowe, ale większość komercyjnych projektów ma jasno zdefiniowaną strukturę. Projekty i zadania są planowane, przypisywane, estymowane, mają deadline'y. Ludzie są dzieleni na streamy/zespoły, zasoby ludzkie są dokładnie znane. To się przekłada na sposób rozwoju kodu, a to z kolei na wymagania stawiane VCS-owi. Git nie ma tu do zaoferowania niczego na tyle cennego, by zrównoważyć koszt migracji.
Względem CVS/SVN? Lepsze łączenie branch'y. Ogólnie? Zależy od polityki firmy względem VCS'ów. Jeżeli nie możesz commitować póki kod nie przejdzie wszystkich testów, a że testy trwają długo? Pech. To zaczynasz robić duże commity. Przy okazji dużych commitów rozwiązujesz problem ciężkiego łączenia branch'y. Ale co za sens mieć duże commity?
Ogólnie polecam wykład Linusa nt. git'a (http://www.youtube.com/watch?v=4XpnKHJAok8). Nie mam takiego doświadczenia w pracy komercynej nad projektami Open Source (jakby jedno z drugim się wykluczało, co zdajesz się sugerować) jak Torvalds, więc myślę, że jego wykład lepiej to wytłumaczy.
17 Kwi 2009, 00:54:48
"Git tworzy brach szybciej niż SVN, również szybciej i lepiej je łączy. Poza tym po co komu branche skoro nie można ich łatwo połączyć."
Setki userów dają sobie radę. Nawet z CVS można spokojnie branchować i mergować, pod warunkiem że całość nadzoruje ktoś kompetentny, potrafiący dopasować politykę branchowania do ograniczeń narzędzia. A szybkość branchowania nie gra roli w większości projektów. Gra role w przypadku kernela, ale takie projekty to mniejszosc.
"To git ma jakieś specyficzne zalety, które powodują że git nie jest przydatny dla nie-specyficznych zastosowań? "
jeśli masz metodologię rozwoju kodu do której dobrze pasuje model scentralizowanego repo z jasno okreslona polityką branchowania, to git będzie najwyżej używany w trybie "emulacji CVS". A wtedy nie ma powodu by po niego sięgać.
Poza tym nie przekonasz nikogo w tzw. "enterprise" jesli powiesz "wskutek magicznych okolicznosci developer znalazl sie poza biurem, w dziczy, odciety od sieci, i akurat musi pilnie cos poprawic w kodzie, commitujac zmiany do swojego lokalnego repo". To argument typu "nie przenoscie swoich aplikacji na cloudy, bo co zrobicie jak cloud Amazona czy Google ktoregos dnia przestanie dzialac?".
"Pokaż mi linuksowe IDE/RAD które nie wspiera git'a."
Musi być linuksowe? No dobra, Eclipse. I poproszę od razu o widok z anotacjami zmian.
Slyszalem o jednym jak do tej pory pluginie do git-a, w stadium baaardzo wczesnej alfy.
"Nadal nie jest to argument świadczący przeciw rozproszeniu."
Tym bardziej nie jest to argument za rozproszeniem.
Masz wieksza szanse ze stracisz dane ze stacji roboczej niz serwera. Dlatego firmy wola, by kod lezal u nich. Gdy zachorujesz, stracisz laptopa albo zostaniesz z dnia na dzien wylany, to przynajmniej maja caly kod ktory do tej pory opracowales i ktos moze go szybko przejac.
"Racja, mamy stado baranów to lepiej się nimi zatroszczyć niż zmusić ich do nauki"
1. nieznajomosc git-a nie czyni kogos baranem
2. znalezc i zatrudnic team dobrych programistow jest bardzo trudno. znalezc i zatrudnic team dobrych programistow potrafiacych sprawnie korzystac z git-a to wrecz "mission impossible".
"Ciekawe co by na studiach o tym powiedzieli"
Uczelnie istnieja po to, by uczyc. Komercyjne organizacje istnieja po to, by zarabiac pieniadze. Dlatego kieruja sie roznymi zasadami.
"To, że branch jest lokalnie nie znaczy że nie można go wypchnąć na zewnątrz."
Jesli czesto wypychasz zmiany na zewnatrz (np. pod koniec kazdego dnia), to po co Ci lokalny branch?
"Ogólnie polecam wykład Linusa nt. git'a"
Wolalbym kogos, kto jest mniej uwiklany w open source i rozwoj git-a. Kogos, hmm, bardziej niezawislego :)
17 Kwi 2009, 01:47:46
"Setki userów dają sobie radę. Nawet z CVS można spokojnie branchować i mergować, pod warunkiem że całość nadzoruje ktoś kompetentny, potrafiący dopasować politykę branchowania do ograniczeń narzędzia. A szybkość branchowania nie gra roli w większości projektów. Gra role w przypadku kernela, ale takie projekty to mniejszosc."
Przez szybkość merge'owania miałem na myśli ile to czasu zajmuje człowiekowi. Co do tego co napisałeś... to jest doskonałym przykładem tego jak _nie_powinna_ rozwijać się informatyka. Z Twoim punktem widzenia do tej pory byśmy używali tylko patch'y nie mając pojęcia co to jest VCS, że już nie wspomnę o wymyślaniu nowych języków programowania.
"jeśli masz metodologię rozwoju kodu do której dobrze pasuje model scentralizowanego repo z jasno okreslona polityką branchowania, to git będzie najwyżej używany w trybie "emulacji CVS". A wtedy nie ma powodu by po niego sięgać."
Jeżeli uważasz że git może co najwyżej pracować jako "emulacja CVS" to jest to doskonały argument że nie powinieneś wypowiadać się na ten temat. VCS jest narzędziem. Ma nam przechowywać kod, dawać branche, łatwo je merge'ować, cokolwiek nie robimy ma być szybko, łatwo, sprawnie. Poświęcanie czasu na zamartwianie się jak tu ułożyć wszystko, zeby nam później CVS nie protestował pochłonie więcej czasu, zasobów i pieniędzy niż przejście, na "nietrafiony" model rozproszony.
"Musi być linuksowe? No dobra, Eclipse. I poproszę od razu o widok z anotacjami zmian.
Slyszalem o jednym jak do tej pory pluginie do git-a, w stadium baaardzo wczesnej alfy."
Linuksowy, bo jako tako git na windę (mówiłem już że ten system nie nadaje się do pracy?) nie istnieje. Co do pluginu to chyba nie patrzymy na ten sam.
"Tym bardziej nie jest to argument za rozproszeniem."
Czy jest to argument który nie wpływa na debatę.
"Masz wieksza szanse ze stracisz dane ze stacji roboczej niz serwera. Dlatego firmy wola, by kod lezal u nich. Gdy zachorujesz, stracisz laptopa albo zostaniesz z dnia na dzien wylany, to przynajmniej maja caly kod ktory do tej pory opracowales i ktos moze go szybko przejac."
Opierasz się na dużych commitach (co jest złe) oraz na braku rozproszenia w rozproszeniu (co też jest złe). Masz ten DVCS więc kod jest trzymany w wielu miejscach na raz. A póki ktoś go od Ciebie nie pulluje to równie dobrze Ty możesz nie wysłać go na centralny serwer. ryzyko takie same. A prawdopodobieństwo, że padnie centralny serwer jest znacznie większe niż że padnie kilkanaście stacji roboczych.
"1. nieznajomosc git-a nie czyni kogos baranem"
Ale nie wybieranie narzędzi lepszych w miejsce gorszych już tak.
"2. znalezc i zatrudnic team dobrych programistow jest bardzo trudno. znalezc i zatrudnic team dobrych programistow potrafiacych sprawnie korzystac z git-a to wrecz "mission impossible"."
A po co szukać tych którzy potrafią gita? Dobry zespół wystarczy. Jak są tacy dobrzy to opanowanie git'a w podstawowych wymaganiach zajmie im godzinę.
"Jesli czesto wypychasz zmiany na zewnatrz (np. pod koniec kazdego dnia), to po co Ci lokalny branch?"
Bo może chcesz coś sprawdzić, co jak Ci się nie uda nikt nie musi oglądać? Może wolisz mieć pojedyńcze małe commity które jak w pewnym momencie coś przestanie działać możesz łatwo i automatycznie przetestować i znaleźć ten w którym się coś skopało (wspominałem o tym, że git takie coś wspiera?).
"Wolalbym kogos, kto jest mniej uwiklany w open source i rozwoj git-a. Kogos, hmm, bardziej niezawislego :)"
Polecam zapytać firmy które korzystają z BitKeepera (taki komercyjny rozproszony system kontroli wersji): http://www.bitkeeper.com/Customers.html
17 Kwi 2009, 06:09:14
> Ale nie wybieranie narzędzi lepszych w miejsce gorszych już tak.
Oczywiście, jest to sugestia, że git zawsze jest lepszy? Niech więc gitowcy kupią mi nowy dysk twardy, specjalnie na repozytoria, które muszę ściągać.
17 Kwi 2009, 09:10:45
"Przez szybkość merge'owania miałem na myśli ile to czasu zajmuje człowiekowi."
W korporacji, gdzie nietrywialne merge robi sie raz na pare tygodni/miesiecy, nie jest to pewnie az tak wazne. Poza tym w poprzedniej firmie robilem cotygodniowe merge rzeczy z kilku branchy do trunka i rzadko zajmowalo mi to wiecej niz poranek. Przy odpowiedniej organizacji pracy to naprawde nie jest istotny problem. W przypadku rozproszonych projektow Open Source jest oczywiscie inaczej, bo tam software rozwija sie w inny sposob i taki SVN jest duzo trudniejszy w uzyciu, robi sie wiecej mergy itp.
"Jeżeli uważasz że git może co najwyżej pracować jako "emulacja CVS" to jest to doskonały argument że nie powinieneś wypowiadać się na ten temat."
Widze, ze po prostu nie chcesz zrozumiec. Dobra, wyjasnie po raz trzeci -- jesli i tym razem udasz, ze nie rozumiesz, to odpuscmy sobie rozmowe.
Masz firme, ktora ma CALY model rozwoju softu zorientowany wobec centralnego repozytorium. Ma to wplyw na wszystko, od organizacji zespolow az po liczebnosc, proporcje miedzy koderami/testerami/analitykami, a nawet wielkosc wynajmowanych biur czy podejscie do outsourcingu. W wiekszosci wypadkow Git bylby w takiej firmie uzywany dokladnie tak samo, jak uzywano tam do tej pory CVS czy SVN-a. I teraz musisz sobie doliczyc koszt migracji -- po pierwsze, przyuczenie userow do uzywania narzedzia. Po drugie, niedostatki git-a pod Windowsem (ktory to sklada sie na wiekszosc stacji roboczych). Po trzecie, opracowanie procedur ratunkowych. Po czwarte, integracja w obecnej infrastrukturze -- podpiecie Git-a pod np. serwery http (jak svn), wpiecie go w continuous integration (zakladajac, ze w ogole dasz rade to latwo zrobic), opracowanie nowych zalecanych praktyk pracy etc. No i robisz rachunek zyskow i strat...
W mojej poprzedniej firmie rozwazalismy migracje na git-a, ale odpadl szybko przez linuksocentrycznosc (a u nas kazdy pracownik mogl sobie wybrac na czym chce pracowac, wiec mielismy mieszanke win/lin/mac) i niezbyt rozbudowana integracje z IDE.
"Ale nie wybieranie narzędzi lepszych w miejsce gorszych już tak."
Podstawowa zasada IT: narzedzia dobieraj do potrzeb. Oraz "jesli dziala dobrze, to nie dotykaj, bo tylko stracisz czas". Wyjatkow jest malo.
"Opierasz się na dużych commitach (co jest złe)"
Nie wiem gdzie dostrzegles duze commity. Jestem agilowcem, zakladam ze kazdy commituje przynajmniej raz dziennie.
"oraz na braku rozproszenia w rozproszeniu (co też jest złe)."
Ja w ogole nie potrzebuje rozproszenia!
"A póki ktoś go od Ciebie nie pulluje to równie dobrze Ty możesz nie wysłać go na centralny serwer. ryzyko takie same."
No to po co mi "rozproszenie"?
"A prawdopodobieństwo, że padnie centralny serwer jest znacznie większe niż że padnie kilkanaście stacji roboczych."
Chyba w projekcie open source... Moja poprzednia firma miala serwerownie dzialajaca bez wiekszych klopotow od kilku lat. Modernizowano sprzet, wymieniano/dodawano dyski i ram itp., ale wszystko bylo dobrze kontrolowane. Nawet jesli padala jakas maszyna (zdarzylo sie chyba trzy razy), to jej miejsce przejmowal od razu jakis zastepczy komputer czy po prostu inny node z klastra.
Tymczasem w normie bylo, ze np. przynajmniej raz na miesiac jakis pracownik uzywajacy Ubuntu sobie odcinal dostep do pulpitu, bo zaktualizowal sterowniki do grafy czy cos w ten desen.
"Bo może chcesz coś sprawdzić, co jak Ci się nie uda nikt nie musi oglądać?"
Od tego mam Eclipse. Prowadzi lokalną historię zmian.
"Może wolisz mieć pojedyńcze małe commity które jak w pewnym momencie coś przestanie działać możesz łatwo i automatycznie przetestować i znaleźć ten w którym się coś skopało"
Do automatycznych testow nie trzeba miec VCS. Jesli po wprowadzeniu zmian nie jestes pewien, czy czegos nie skopales, to jest to oznaka kiepskich testow/pokrycia i to to nalezy zmieniac. A jesli musisz powprowadzac tyle zmian, ze nawet mimo testow jest duze ryzyko skopania czegos, to znaczy ze task ktory wykonujesz zostal nieprawidlowo okreslony (story z za duzym ryzykiem, za duzo story points wg. modnych metodologii rozwoju softu). Rozbij swoje zadania na dobrze okreslone, male moduly; zadbaj o pokrycie testami. Rollbacku "bo cos nie dziala" nie musialem robic od lat. TDD zalatwia ten problem za mnie.
Widzisz, kazdy problem da sie jakos ugryzc. Jedni wymagaja wiecej od VCS, inni od samej organizacji pracy. Jak dlugo sie sprawdza, to nie ma sprawy. Tarcia sie pojawiaja, gdy ktos nie moze zrozumiec, ze nie ma idealnego rozwiazania dobrego dla wszystkich (i np. probowalby przeciagnac kernel na SVN).
18 Kwi 2009, 09:59:50
bq. Jeżeli uważasz że git może co najwyżej pracować jako "emulacja CVS" to jest to doskonały argument że nie powinieneś wypowiadać się na ten temat.
@Matthew: Na wszelkie bóstwa! Nie strzelaj taką argumentacją w przypadku systemu kontroli wersji, którego zachwala się, jako takiego, który wspiera niemal wszystkie możliwe workflow ;p Np. te wspomniane na stronie WhyGitIs...
- Subversion-Style Workflow,
- Integration Manager Workflow,
- Dictator and Lieutenants Workflow.
21 Kwi 2009, 12:05:42
i Co MAtthew, jak poszlo z GSOC ?
21 Kwi 2009, 14:06:55
@Hoppke:
"W korporacji, gdzie nietrywialne merge robi sie raz na pare tygodni/miesiecy, nie jest to pewnie az tak wazne. Poza tym w poprzedniej firmie robilem cotygodniowe merge rzeczy z kilku branchy do trunka i rzadko zajmowalo mi to wiecej niz poranek. Przy odpowiedniej organizacji pracy to naprawde nie jest istotny problem. W przypadku rozproszonych projektow Open Source jest oczywiscie inaczej, bo tam software rozwija sie w inny sposob i taki SVN jest duzo trudniejszy w uzyciu, robi sie wiecej mergy itp."
Ale wybranie narzędzia które łatwiej robi merge jest lepszym rozwiązaniem niż męczenie się z CVS/SVN. Nawet jeżeli jest to system centralny, to uważam, że lepiej zmienić narzędzia. Pomimo, że na krótką metę zysk może być niewielki, lub go nie być wcale, to przez X lat zysk się pojawi.
"Podstawowa zasada IT: narzedzia dobieraj do potrzeb. Oraz "jesli dziala dobrze, to nie dotykaj, bo tylko stracisz czas". Wyjatkow jest malo."
Dlatego, że ludzie nie potrafią patrzeć w dłuższej perspektywie. To co teraz może Ci zajmować jeden ranek w tygodniu, po zmianie VCS mógłbyś robić w mniej niż godzinę.
Należy wybierać narzędzia które wspierają nasz sposób pracy. Wtedy odbywa się to naturalniej i szybciej. Zamiast stosować sztuczne kontrole i zabiegi które mają za zadanie łatanie niedoskonałości narzędzi. Marnujemy tylko czas i pieniądze.
"Tymczasem w normie bylo, ze np. przynajmniej raz na miesiac jakis pracownik uzywajacy Ubuntu sobie odcinal dostep do pulpitu, bo zaktualizowal sterowniki do grafy czy cos w ten desen."
Nie mówiłem, że Ubuntu jest beznadziejne? ;P
"Od tego mam Eclipse. Prowadzi lokalną historię zmian."
Czyli to co ja przerzucam na DVCS Ty masz w Eclipse, ale idea podobna.
@daytek:
Szkoda gadać. xD
21 Kwi 2009, 15:19:38
"Ale wybranie narzędzia które łatwiej robi merge jest lepszym rozwiązaniem niż męczenie się z CVS/SVN"
Oczywiście, jeśli zaczynasz od zera. Ale jeśli masz już jakiś istniejący system na miejscu, to pojawia się koszt migracji.
"To co teraz może Ci zajmować jeden ranek w tygodniu, po zmianie VCS mógłbyś robić w mniej niż godzinę."
W teorii. W praktyce może się okazać, że np. 80% pracy było odwalane przez integrację repozytorium kodu - system zarządzania taskami (np. SVN-Jira, czy CVS-Bugzilla), i po zmianie na bardziej egzotyczny VCS co prawda mergowanie idzie szybciej, ale powiadamiać testerów o poprawkach przeportowanych z jakiegoś brancha musisz już ręcznie.
Poza tym liczy się jeszcze stosunek czasu spędzanego na mergowaniu do pozostałych czynności wykorzystujących VCS (w tym czynności związane z administracją, bezpieczeństwem itp.).
To jak z optymalizowaniem kodu -- nie ma co tracić zasobów na optymalizowanie fragmentu, w którym spędzasz tylko 2% czasu.
"Nie mówiłem, że Ubuntu jest beznadziejne? ;P"
Nie to, że Ubuntu jest beznadziejne. Większość ludzi brała jakąś odmianę Win (na ogół XP SP2), ja też, bo to był wtedy najlepszy OS do kodowania w Javie. Linuksa brali tylko nałogowi "power userzy". A wiadomo, że PU nie wytrzyma bez grzebania w systemie. I jazda, testowe repozytoria, dłubanie w pakietach, aktualizacje do niestabilnych wersji... Na dodatek większość systemów miała grafikę ATI, a wszyscy chcieli mieć desktopy 3d... A jak się zrypało, to wołali adminów :)
"Czyli to co ja przerzucam na DVCS Ty masz w Eclipse, ale idea podobna."
Jasne. Dlatego gitowi trudniej się wbić w niektóre środowiska, bo tam już jakoś załatano część problemów.
BTW, tak w ogóle to uważam, że mergowanie nie powinno być zajęciem dla VCS. VCS powinien zarządzać branchami itp., ale mergowanie, rozwiązywanie konfliktów powinno robić coś wyspecjalizowanego, leżącego nad VCS. Cały czas czekam na NAPRAWDĘ dobrą maszynę do mergowania, działającą z większością VCS-ów przez zestaw adapterów :)
21 Kwi 2009, 19:31:26
@Hoppke:
"Oczywiście, jeśli zaczynasz od zera. Ale jeśli masz już jakiś istniejący system na miejscu, to pojawia się koszt migracji."
Kwestia czy ten koszt jest na tyle duży że nie opłaca się migrować? Niestety nikt nigdy takich statystyk pewnie nie zrobi. Ja uważam, że migracja z CVS'a na git'a (pomijając już kwestię rozproszenia) w krótkim czasie by się zwróciła.
"Poza tym liczy się jeszcze stosunek czasu spędzanego na mergowaniu do pozostałych czynności wykorzystujących VCS (w tym czynności związane z administracją, bezpieczeństwem itp.)."
Akurat w tych kwestiach git bije na głowę masę innych OpenSource'owych VCS. W czasach w których był tworzony chyba tylko Monotone zapewniał bezpieczeństwo kodu (w sensie to co włożysz do kodu będzie tym co z niego wyciągniesz). Co do administracji, odpada kwestia praw dostępu, każdy ma dostęp do swojego własnego repo.
"A jak się zrypało, to wołali adminów :)"
To jacyś kijowi Ci PU skoro robią na Ubuntu, rypie się im i jeszcze wołają adminów.
"BTW, tak w ogóle to uważam, że mergowanie nie powinno być zajęciem dla VCS. VCS powinien zarządzać branchami itp., ale mergowanie, rozwiązywanie konfliktów powinno robić coś wyspecjalizowanego, leżącego nad VCS. Cały czas czekam na NAPRAWDĘ dobrą maszynę do mergowania, działającą z większością VCS-ów przez zestaw adapterów :)"
Raczej niemożliwe. Każdy VCS musiałby zapewniać te same dane dla systemu mergeującego. A z tym trudno w przypadku CVS'a. ;] Dodatkowo pozostaje kwestia jak rozwiązać konflikty? Skąd taki programik ma wiedzieć czy ta funkcja nie robi to samo co inna z którą jest konflikt lub czy dany fragment kodu jest szybszy od innego.
22 Kwi 2009, 11:26:19
"Kwestia czy ten koszt jest na tyle duży że nie opłaca się migrować?"
No i to już każdy zespół/firma musi sobie oszacować indywidualnie. Wydaje mi się, że "problem" z większością komercyjnych projektów polega na tym, że ludzie nie mogą tam za bardzo wybierać sobie konkretnych zadań. Np. chciałbym przemigrować główny projekt z frameworku foo-2.5 na foo-3.0, ale nie dostanę na to czasu, bo muszę w pierwszej kolejności dodać funkcje wymagane przez nowego klienta. Z migracjami w infrastrukturze jest tak samo; dopóki coś nie jest napraaaaawdę mocno uciążliwe, to zawsze usłyszę "są teraz ważniejsze/pilniejsze rzeczy do roboty"
"Co do administracji, odpada kwestia praw dostępu, każdy ma dostęp do swojego własnego repo."
Ale nadal masz centralne repo i ono musi być zarządzane. Nawet w linuksie Linus ma iluś-tam zaufanych pomocników, żeby nie być wąskim gardłem. A "swoje własne" repo można było mieć od dawna, choćby przez TortoiseSVN (file://...).
Osobne, prywatne repo jest fajne w OS, bo masz otwartą, bliżej nieznaną liczbę potencjalnych autorów zmian. Ale w firmie, gdzie do kodu dopuszczasz tylko ludzi, których wcześniej sam zrekrutowałeś, nie ma powodu by wszyscy członkowie zespołu nie mieli dostępu do hostowanego w firmie repo.
Więcej nawet, gdyby mi mój przełożony powiedział, że mam mu podsyłać wszystkie swoje poprawki do akceptacji i że nie będę miał własnego prawa zapisu do repo, to bym po prostu odszedł, bo odbieram to jako kwestionowanie moich kompetencji/intencji i ogólnie debilną metodę zarządzania pracą "core teamu".
"To jacyś kijowi Ci PU"
Jedni używają Ubuntu, inni Gita. Każdy wybiera to co lubi...
"Każdy VCS musiałby zapewniać te same dane dla systemu mergeującego."
Niektóre dostarczałyby więcej informacji, inne mniej. System mergujący musiałby sobie radzić z tym, co mu zaserwowano. Z gorszymi VCS-ami by po prostu mniej automagicznie działał. Ale to tylko takie moje fantazjowanie :)
13 Maj 2009, 23:59:09
@Adam: racja.
Dodałbym, że to jest żywcem zerżnięte od 4 akapitu, choć ze skrótami. I w~takim razie to autor powinien wspomnieć o~wykładzie Torvaldsa.
04 Lip 2009, 16:57:10
Matthew: "Problem zaczyna się wtedy kiedy masz na prawdę wielkie repozytorium, gdyż przy pierwszym pobraniu musisz ściągnąć całe. Rozwiązać to można poprzez tworzenie małych repozytoriów z częściami projektu i jednego superrepozytorium które zawiera dowiązania do mniejszych."
na szczęście jest jeszcze coś takiego jak "git-clone --depth 1 $URL", dzięki czemu pobiera się 2 ostatnie commity (HEAD + 1 commit, nie można podać 0, bo lecą wszystkie)
niestety taki klon ma swoje ograniczenia...