Git, Bazaar, Mercurial - Subversion pod obstrzałem

Opublikowane przez Jarosław Zabiełło Wed, 19 Mar 2008 11:00:00 GMT

Świat technologii IT zmienia się coraz szybciej. Nie minęło wiele lat od dosyć masowego przechodzenia CVS do Subversion a już zanosi się na kolejną rewolucję. Tak jak wcześniej atakowany był CVS, teraz atakowany jest Subversion. Atakowany jest przez rozproszone systemy kontroli wersji.

Czym jest system rozproszony (distributed)?

Subversion jest przykładem centralnego systemu wersjonowania. Zawsze mamy do czynienia z centralnym repozytorium kodu. Jakakolwiek próba ściągnięcia nowszych wersji plików wymaga posiadania połączenia z serwerem zawierającym interesujące nas repozytorum. Jakakolwiek aktualizacja zmian w repozytorum wymaga znowu połączenia się z centralnym repozytorium. Systemy rozproszone działają zupełnie inaczej.

Po pierwsze, nie posiadają żadnego centralnego repozytorium. Ściągnięcie projektu polega na sklonowaniu danego repozytorium na dysku lokalnym. Wszelkie lokalnie dokonywane zmiany należy dodawać do swojego, lokalnego repozytorium. Nie jest potrzebne posiadanie aktywnego połączenia z internetem. Co w wypadku, kiedy pierwotne repozytorium się zmieniło i chcemy zaktualizować swoje? Nic trudnego.

Drugą, potężną różnicą w stosunku do Subversion jest łatwość z jaką w systemie rozproszonym scala się dowolne odgałęzienia (branches) kodu. Subversion jest bardzo tu kiepskie. System rozproszony pozwala zatem posiadać najnowszą wersję kodu oryginalnego włącznie z naszymi poprawkami. Jeśli chcemy wysłać nasze zmiany do autora projektu, można to także uczynić. Jeśli autor uzna, że nasze zmiany są wartościowe i godne tego aby je dołączyć, stosuje podobny mechanizm scalania odgałęzień.

Trzecią istotną różnicą jest brak zaśmiecania projektu dziesiątkami folderów o nazwie .svn (W Subversion każdy wewnętrzny folder, aby podlegał wersjonowaniu, musi posiadać w środku taki dodatkowy folder). Systemy rozproszone zwykle tworzą jeden, jedyny folder w głównym katalogu i nie wymagają aby wszystkie wewnętrzne foldery posiadały go również.

W praktyce, porządnie prowadzone projekty używające Subversion stosują jakieś formalne reguły dodawania zmian w kodzie. Np. zabrania się “commitowania” kodu, który nie przeszedł pozytywnie wszystkich testów jednostkowych. Problem w tym, że od chwili zgrania sobie źródeł na dysk, tracimy wszelką możliwość wersjonowania naszych małych, lokalnych zmian (które niekoniecznie muszą być pozbawione błędów). Czasami chcemy się cofnąć do jakiejś wcześniejszej zmiany i nie możemy. Subversion wersjonuje tylko kod w centralnym repozytorium. System rozproszony pozwala zaś na takie śledzenie lokalnych zmian i to nawet w sposób niezależny od ściągniętego kodu z repozytorium Subversion. Niezależny, bo można trochę “oszukiwać” system używany w pracy. :) Po ściągnięciu kodu z SVN, można dodać sobie lokalnie system rozproszony i kontrolować swoją historię lokalnych zmian w sposób nieinwazyjny dla Subversion.

Git, Mercurial i Bazaar

Aktualnie, najbardziej liczące się systemy rozproszone to Git, Mercurial i Bazaar.

Git

Pierwotnie stworzony przez Linusa Torvaldsa do zarządzania kodem jądra systemu Linux, Git zaczyna dosyć przebojowo zdobywać popularność. Pomijając oczywistą wyższość systemu rozproszonego nad system centralnego repozytorium, trzeba podkreślić, że Git bardzo szybki. Niezrównanie szybszy od Subversion, szybszy też od Mercurial i Bazaar. Coraz więcej projektów zaczyna przechodzi na Git’a (np. konkurent RailsówMerb trzyma źródła repozytorium Git’a, zobacz też “Contributing to Merb” – Part 1 i Part 2)

Także (napisany w Ruby) system do aktualizacji projektów na serwerze (deploying) – Capistrano – posiada wsparcie dla Git’a. Duża rolę w popularyzacji Git’a czynią serwisy takie jak github.com czy gitorious.org gdzie można założyć darmowe konto dla swoich projektów. A do śledzenia błędów i zgłaszania poprawek kodu trzymanego w githubie można użyć serwisu http://lighthouseapp.com.

Railscasts.com znany serwis ze dziesiątkami darmowych filmów edykacyjnych dla Railsów, dodał niedawno screencast opisujący integrację Git’a z Rails. Trochę dłuższy film na ten temat jest dostępny też w serwisie peepcode.com. Zobacz także poniższą prezentację Linusa Torvarldsa n/t GIT’a. Linus nie przebiera w słowach krytyki wobec Subversion, nazywając go po prostu głupim pomysłem. Subversion to tylko poprawiony, stary CVS. Nie wnosi jednak nic specjalnie nowego i jego koniec jest bliski. ;)

Mercurial

Mercurial, to system rozproszony napisany w Pythonie. Z definicji jest więc multiplatformowy (bieżąca implementacja Git’a dla win32 jest dosyć słaba). Zasadniczo niewiele się różni od Git’a. Jest trochę wolniejszy, nie ma (przynajmniej ja nie znam) jakichś popularnych darmowych kont do trzymania projektów. Ale jego zaletą jest wspomniana wyżej multiplatformowość (działa na win32 bardzo dobrze) oraz integracja z edytorem Netbeans 6 (jeszcze trwają prace nad integracją z Git’em). Firma Sun wybrała też Mercurial jako następcę dla Subversion. Są też mniejsze firmy które zdecydowały się na Mercurial z powodu lepszej integracji z systemem Windows, ale są gotowe przejść na szybszego Git’a jak tylko zostanie poprawiona jego wersja dla win32.

Bazaar

Bazaar, podobnie jak Mercurial, napisany został w Pythonie. Nie ma więc problemów z działaniem pod systemem innym niż POSIX. Jest to dosyć ciekawy system, bo potrafi pracować zarówno jako system centralny jak i rozproszony. Jego twórcy są mocno przekonani o wyższości Bazaar nad Git, Mercurial i Subversion, o czym świadczy zamieszczone przez nich śmiałe porównanie z tymi systemami. (Niektóre stare porównania Git’a z Bazaar podkreślały znaczną przewagę szybkości Git’a, ale niestety najczęściej dotyczyły one starej, wolniejsze wersji Bazaar. Od wersji 1.0 poprawiono jednak znacznie wydajność i ten argument trochę stępił swoje ostrze krytyki).

Bazaar posiada, podobnie jak Git, serwer z darmowymi kontami na projekty – launchpad. To może pomóc spopularyzować ten system. Bazaar ma dostępny wygodny plugin do Eclipse. Co do Netbeans 6, są jakieś plany, ale na razie nie wiadomo czy i kiedy dodadzą wsparcie.

Updates

2008-03-23

Użytkownicy OSX 10.5.2 (Leoparda) instalują Gita za pomocą MacPortów (warto dodać wariant +svn aby mieć dostęp do skrypty git-svn; warianty dostępne dla Git’a sprawdza się za pomocą komendy port variants git, a odświeżenie listy portów: sudo port -d sync).
sudo port install git-core +svn

Jeśli instalacja wywali się z powodu problemów z SQlite3, należy doinstalować gmake, czyli:

sudo su
port install gmake
port clean sqlite3
port install sqlite3
port install git-core +svn

Tagi , , , , ,  | 25 comments

Comments

  1. Avatar marek powiedział about 4 hours later:

    “Aktualnie, najbardziej liczące się systemy rozproszone to Git, Mercurial i Bazaar.” – na podstawie jakich danych stwierdzasz to?

  2. Avatar kulfon powiedział about 5 hours later:

    @marek, a może ty się podzielisz swoją wiedzą, skoro znasz inne..

  3. Avatar Uzytkownik powiedział about 9 hours later:

    @kulfon: Jest jeszcze choćby BitKeeper i kilka innych.

    Ale IMHO w środowisku FLOSS te 3 są najbardziej rozpowszechnione. W tym chyba git najbardziej a mercurial na drugim miejscu (wspierany przez SUN). Osobiście najbardziej lubię bzr (choć mercuriala nie próbowałem).

  4. Avatar Husio powiedział about 9 hours later:

    Jak wybierałem system kontroli wersji, testowałem bazaar i git. SVN odpadło bo wymaga serwera, reszta nie jest open source, więc była na ostatnich miejscach w kolejce.

    Szybko zrezygnowałem z bazaar, bo sypał jakimiś błędami i był wtedy o wiele wolniejszy. Został więc git. Ma dobre wsparcie społeczności, wiele osób o nim pisze. Wszyscy, poza nielicznymi przypadkami, zachwalają. Chyba tylko na windows mogą być problemy, ale nie ma to dla mnie znaczenia.

  5. Avatar Zboczuch powiedział about 20 hours later:

    Wszystko ładnie, lecz nie zauważyłem w artykule jakiejkolwiek krytyki rozproszonych systemów kontroli wersji. A przecież wiele zależy od zastosowań. I tak chwalona niezależność repozytoriów stać się może prawdziwym utrapieniem, gdy autor projektu zmuszany jest nieustannie scalać nadsyłane mu poprawki.

    W niewielkiej wielkości firmie (6 programistów) wymagać to może już wydzielenia mnóstwa czasu dla osoby zajmującej się scalaniem poprawek, co w przypadku Subversion przy mądrym commitowaniu i częstych update’ach zmniejsza ten czas do minimum, dodatkowo rozkładając go (równolegle) na wiele osób.

    Są dla GIT (lub innych) narzędzia wspierające automatyczne scalanie kodu? Czyli tak naprawdę symulujące Subversion ;)?

  6. Avatar SeeM powiedział about 20 hours later:

    No ale rozproszone systemy są po to, żeby nie trzeba było ciągle nadzorować nadsyłanych łatek, tylko każdy robi w swojej piaskownicy i kiedy dojdzie do wniosku, że coś zrobił, to ogłasza że ma coś zrobionego i reszta sobie sama “commitnie” jak będzie chciała.

    Na 6 osób Subversion w zupełności wystarczy, bo wszyscy mają ze sobą bezpośredni kontakt a to daje o wiele więcej niż jakikolwiek system kontroli.

  7. Avatar Dentharg powiedział about 21 hours later:

    Kiedyś już na ten temat blogowałem ; w komentarzach wywiązała się (MSZ) całkiem niezła dyskusja.. Zapraszam.

    U nas SVN jest używane przez 3 międzynarodowe zespoły (w Polsce, w Rosji i w Niemczech; serwer w Polsce) i powoli przestaje dawac radę (>20K plików, >12K rewizji). Jednak w por. do systemów rozproszonych daje dokładniejszą kontrolę nad tym co i komu się daje.

  8. Avatar hm powiedział about 22 hours later:

    Ja już wybrałem Mercurial. Od razu przypadł mi do gustu. Posiada bardzo dobrą dokumentację http://hgbook.red-bean.com/ Netbeans będzie oferował dla niego wsparcie w standardzie od wersji 6.1.

    Źródła OpenJDK (uwolnionej wersji Javy) trzymane są od grudnia 2007 na http://hg.openjdk.java.net/

    Prezentacja Google TechTalks o Mercurial z czerwca 2006: http://video.google.com/videoplay?docid=-7724296011317502612

    @Zboczuch: rozproszone scm są tworzone z myślą o forkowaniu i mergowaniu. Właściwie dobrany system pracy zmniejsza dodatkowo niedogodności związane ze scalaniem kodu do minimum. Polecam rozdział 6.2 “Collaboration models ” ze wspomnianej książki “Distributed revision control with Mercurial”. Zobacz w jaki sposób pracują nad OpenJDK http://blogs.sun.com/kto/entry/openjdk_mercurial_forest

  9. Avatar forgems powiedział 1 day later:

    Na podstawie doświadczenia moge stwierdzić że bzr jest jednym z najwolniejszych systemów kontroli wersji. Nie polecam go i znam co najmniej 15 osób które mają o nim podobne zdanie.

    W przypadku wyboru systemu kontroli wersji skupiłbym się raczej na Git-cie i Mercurial-u, z ukierunkowanie na tego pierwszego (większy user base).

  10. Avatar Jan Koprowski powiedział 1 day later:

    Ja w projekcie, który piszę obecnie zdecydowałem się na bazaara. Przeoczyłem fakt, że można trzymać repozytoria na darmowym serwerze, natomiast zauważyłem, że wystarczy zwykłe FTP do trzymania repo (czy SSH). Był to na moje oko jedyny system wersjonowania, który dawał takie możliwości, dlatego u mnie wygrał.

  11. Avatar Szymon powiedział 3 days later:

    A to nie wystarczy zwykły SVN z tym, że każdy ma swoją gałąź ze swoją kopią i jak stwierdzi, że coś tam zrobił to wtedy jest to mergowane do głównego katalogu?

  12. Avatar Ferry rozbrojony powiedział 5 days later:

    Ale SVN pozwala uzywac file : // i wtedy nie trzeba serwera. Mozna to zrobic jako katalog. drobniutkie katalogi .svn rozwiazuje sie poleceniem—export

  13. Avatar Jarosław Zabiełło powiedział 5 days later:

    Tylko, że jak się wyeksportuje w SVN projekt to nie jest on już powiązany z repozytorium. To chyba nie o to chodzi. Git ma skrypt git-svn do używania SVN i Git’a na zasadzie przełączania. Mercurial i Bazaar też coś takiego zdaje się mają.

    @Szymon: SVN ma bardzo kiepskie mergowanie no i jego główną wadą jest to, że musisz to robić w centralnym repozytorium. Git pozwala na lokalne “commity” i potem to można hurtem wypchnąć na serwer. Takie lokalne commity przydają się do kontrolowania lokalnych zmian przed wypchnięciem ich na serwer.

  14. Avatar mwd powiedział 6 days later:

    Jakoś nikt nie wspomniał o monotone – Linus wzorował na nim Gita, jest multiplatformowy, szybki i dynamicznie się rozwija. Kto z niego korzysta? Pidgin, OpenEmbedded, Xaraya…

  15. Avatar Arek powiedział 6 days later:

    Dla osób szukających czegoś bardzo dobrze współpracującego z SVN polecam napisany w PEARL SVK. Może niezbyt szybki ale pozwala nawet na korzystanie z TortoiseSVN. Choć jest systemem rozproszonym to opiera sie na SVNowym systemie plików. Można swobodnie skopiować repozytorium SVN i łatwo synchronizować zmiany z gałęziami SVK.

  16. Avatar Jiima powiedział 7 days later:

    SVK jest ciekawą propozycją, ale raczej jako “łata” na Subversion. A współpraca z narzędziami Subversion też jest daleka od ideału (jak korzystasz z commandline, to mirror = projekt. Jak chcesz korzystać z narzędzi subversion, musisz zrobić checkout z mirrora, czyli de facto korzystasz z SVN a nie z SVK).

    Co do innych, ja osobiście najbardziej lubię Mercuriala, ze względu na integrację z NB i sensowną współpracę z Windowsami (wiem że niektórych to “wali” ale ja jestem dość pragmatyczny i pracuję na tych systemach na które mam zlecenia, a nie na tych które lubię lub mam do nich ideologiczne nastawienie).

    Generalnie, myślę że znów wywiązuje się dyskusja o wyższości świąt. Tak naprawdę to, czy jest centralne repozytorium czy nie, oraz czy git czy mercurial to kwestia gustu i potrzeb danego projektu. Systemy rozproszone wymagają innego podejścia do struktury projektu, zarządzania nim itp. Czasem tak jest lepiej, czasem gorzej. Nie wszystkie projekty budowane są na takiej zasadzie jak jądro Linuxa.

  17. Avatar Jarosław Zabiełło powiedział 7 days later:

    @Arek: Git ma skrypt git-svn do przezroczystej współpracy z SVN.

    @Jiima: Nie wiesz czy Mercurial ma jakiś odpowiednik github.com zintegrowanego z issue trackerem podobnym do lighthouseapp.com? To jest naprawdę wielka rzecz.

  18. Avatar wojtekm powiedział 7 days later:

    Co do darmowego hostingu Mercuriala, to proponuję zapoznać się z Wiki projektu: http://www.selenic.com/mercurial/wiki/index.cgi/MercurialHosting

    Szczególnie 2 ostatnie serwisy są warte uwagi: http://mercurial.intuxication.org/ http://freehg.org/

  19. Avatar wojtekm powiedział 7 days later:

    @Jarosław Zabiełło http://sharesource.org

  20. Avatar Jarosław Zabiełło powiedział 8 days later:

    Te dwa, jakie podałeś są słabe i prymitywne. Trzeci, jest lepszy, ale najbardziej wypasiony wydaje się Assembla. M.in. ładnie integruje Mercurial z Trac.

  21. Avatar Jiima powiedział 10 days later:

    @JZ

    Niestety, jako wredny pies korporacji zwykle nie mam potrzeby korzystania z tego typu sajtów, więc nie wiem. Ale assembla wydaje się OK.

    Z drugiej strony jak skończą pracę nad pushem do repozytoriów Subversion, to nawet Google Code się nada :P

    To z resztą jest główna siła Mercuriala – pluginy do innych sieci i systemów centralnych. Ostatnie doświadczenia z kernelem linuksa pokazały mi, że Mercurial np. świetnie nadaje się do składania customowego kernela z nieoficjalnych repozytoriów (2 – 3 krąg commiterów). Sam nic nie commituje, bo nie hackuje jądra akurat, więc nie wiem jak to z pushem, ale…

  22. Avatar lol powiedział 11 days later:

    Szkoda, że nie ma o sposobach instalacji poszczególnych systemów kontroli wersji. Właściwie sama instalacja nie sprawia kłopotów, ale już udostępnienie repozytorium przez HTTPS na Apache to już nie takie łatwe. O ile w przypadku SVN jest to dobrze opisane, o tyle z Mercurial nie udało mi się znaleźć jasnego opisu. Nie mówię już o Bazaar, który jest chyba najgorzej udokumentowany.

  23. Avatar Jarosław Zabiełło powiedział 22 days later:

    Pojawiło się nowe porównanie Gita z Mercurial.

  24. Avatar Paweł Pacana powiedział about 1 year later:

    @Jarosław Zabiełło http://bitbucket.org – hosting hg, dość podobny do githuba

  25. Avatar Michał Pabis powiedział over 2 years later:

    Aktualnie wiele się zmieniło (tak z szybkością poszczególnych systemów, wsparciem Gita pod Windowsem, szybkością Bazaara, darmowym hostingiem repozytoriów Mercuriala i integracją z trackerami, jego rozbudowaną i bardzo dobrą dokumentacją itp., itd.), warto byłoby zrobić aktualizację ;) Tak czy inaczej – polecam czytelnikom zdobycie także bardziej aktualnych informacji przed dokonaniem wyboru.

(leave url/email »)

   Pomoc języka formatowania Obejrzyj komentarz