(more…)

(more…)

(more…)

(more…)

(more…)

W Sieci jest kilka poradników jak zainstalować Slackware. Niestety, w większości przypadków odnoszą się do starszych wersji Slackware. Również brak lub niewystarczająca znajomość języka angielskiego może być dla wielu osób problemem. Stąd pomysł aby napisać instrukcję instalacji Slackware w wersji 12.1.

(more…)

Ten mini poradnik przeprowadzi Was przez pierwsze kroki z Amarokiem. Pokaże, jak zaimportować kolekcję muzyki, używać radia Last.fm, czy też zarządzać widokiem kontekstowym. (more…)

Wreszcie udało mi się zebrać i zrobić wpis nt. gita. 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).

Czemu Git? Czemu nie SVN?

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.

Kilka słów o historii

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.

Zalety Gita i DVCS

W rozproszonych systemach kontroli wersji (DVCS) 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 gicie 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.

Prywatne gałęzie

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 naprawdę 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!

Sieć zaufania

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.

Szybsze merge’owanie

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.

Eee… Tylko tyle?…

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

Wiadomość źródłowa na blogu autora: git

Odkryjesz prawdę o nim za każdym razem, gdy go użyjesz.
–reddy@lion.austin.com

(more…)

(more…)

(more…)

(more…)

(more…)