Rozproszone systemy kontroli kodu
Od jakiegoś czasu poszukuję systemu kontroli kodu na własne potrzeby. Domyślnie używałem Subversion po pewnym czasie przesiadłem się jednak na Bazaar. Obecnie używam bzr(Bazaar) do przechowywania i wersjonowania zmian w /etc.
Ale przecież jest tyle innych systemów kontroli kodu...
Subversion
Z Subversion jest jeden problem: rozgałęzianie (ang. branching) jest po prostu major PITA. Łącząc (ang. merge) kod wielokrotnie między gałęziami trzeba zawsze zapisywać co już zostało złączone i w jaki sposób, bo nie wybrnie się z konfliktów.
Oczywiście w swoich projektach jeśli chcę wypróbować jakąś funkcjonalność mogę zawsze wziąć świeżą kopię z repo, poeksperymentować i scalić zmiany ręcznie. PITA.
Drugi ważny minus Subversion to niemożność samodzielnego hostowania. Pod tym pojęciem rozumiem to, że mając dowolny hosting nie dam rady na nim postawić repo dostępnego zdalnie; żaden usługodawca nie pozwoli mi postawić repo, uruchomić zdalnego serwera (protokół svn://) ani podpiąć się pod Apache (protokoły http:// i DAV).
Jest łatwiej, jeśli ma się konto shellowe na serwerze. Można wtedy skorzystać z dostępu svn+ssh:// do repozytorium (dzięki Dozzie i Mysz za sprostowanie!)
Bazaar
Za główne atuty Bazaara uważam jego przenoszalność (Bazaar napisany jest w Pythonie) oraz możliwość umieszczenia repozytorium na zdalnym hostingu.
Jego największą wadą jest to, że jest napisany w Pythonie :) Żeby go używać konieczne jest zainstalowanie Pythona – a to nie zawsze rozwiązanie, choć przyznaję, że to najmniejszy problem (bo nie jest problemem na dowolnym kompie zainstalować interpreter; nikt się nie pogniewa). Znacznie ważniejszy problem to prędkość: zanim Bazaar się rozpędzi mija nieco czasu; podobnie przy większych operacjach typu diff, czy merge. Z wersji na wersję jest coraz szybciej ale…
Mercurial
To kolejny system, który chcę wypróbować w praktyce. Jedyny problem jaki znalazłem na razie to fakt, że Mercurial nie umie wypchnąć zmian do zdalnego repozytorium przez protokół FTP (co umie Bazaar).
Choć jest napisany w Pythonie to jest szybszy (sporo!) od Bazaara.
Niewątpliwym plusem dla Mercuriala jest fakt, że sam Linus Torvalds wymienia go jednym tchem obok GITa.
Niedawno Automaciej przedstawiał problem z pamiętaniem i scalaniem zmian nazw katalogów podczas jednoczesnej pracy wielu osób na tym samym kodzie. Z przyjemnością stwierdzam, że Mercurial ów test przechodzi i prawidłowo scala zmiany.
Git
Git ma jedną, ogromną dla mnie, wadę: nie działa na Windows. To znaczy działa, ale tylko w środowisku Cygwina. Ponadto mocno wykorzystuje POSIX -owe operacje na plikach, co niekoniecznie dobrze odbija się na wydajności w Windows.
Poza tą wadą, z testów na sieci wynika, że faktycznie jest obecnie najszybszym DSCM.
Git nie przeszedł testu Automacieja. Jednak jak mówi sam Torvalds: Git śledzi repozytorium na poziomie treści, a nie systemu plików (cokolwiek to oznacza).
Podsumowując: będę czekał na to co stanie się z Bazaarem, na chwilę obecną zastosuję Mercuriala, a w przyszłości spróbuję Gita (bo jest kompilowany i tym samym ma najmniej zależności) gdy tylko pojawi się jakiś fajny fork dla Windows.
±
Komentarze do wpisu "Rozproszone systemy kontroli kodu":
1.
2007 07 12, 23:05:08
> Jednak jak mówi sam Torvalds: Git śledzi repozytorium na poziomie treści, a nie systemu plików (cokolwiek to oznacza).
Oznacza to mniej więcej tyle, że zapamiętywane są całe pliki, a nie tylko różnice między kolejnymi wersjami. A że pliki są zapisywane pod adresami opartymi o skrót SHA-1, to dwa identyczne pliki zajmują w repo tylko połowę z łącznego rozmiaru. Przydaje się to przy repozytoriach z dużymi plikami, np. repozytoriach pakietów binarnych. Extended Slackware dostało takie właśnie repozytorium. W branchach są trzymane całe snapshoty z danego dnia.
Git ma jedną podstawową zaletę: można go bezkarnie używać do umobilnienia kopii roboczej Subversion. Robisz checkout, piszesz, piszesz i commitujesz do gita, a na koniec wprowadzasz zmiany do Subversion.
2.
2007 07 12, 23:07:06
Ale to oznacza, że rozmiar repo jest większy niż w systemach gdzie przechowuje się delty/diffy, tak?
3.
2007 07 13, 00:25:59
Wbrew pozorom nie. Kopia robocza X-serwera X.Org zajmuje 62MB, z czego 25MB to repozytorium git, a najstarszy zapamiętany commit pochodzi z 1999 roku.
4.
2007 07 13, 00:28:51
A Mercurial jest taki szybki bo najważniejsze rzeczy ma napisane C
Bazaar to bardzo fajny system i naprawdę prężnie się rozwija!
5.
2007 07 13, 08:57:53
Co do SVN, to o ile dobrze pamiętam, można go sobie zainstalować na koncie gdzie dają shella, i łączyć się i commitować po ssh. Oczywiście lepiej nie dawać dostępu osobom postronnym do takiego repo, ale to samo chyba dotyczy łączenia się po ftp
6.
2007 07 13, 08:58:51
Niestety tak się nie do końca da. Po SSH i owszem, ale to musi być protokół svn+ssh:// – zatem serwer SVNowy musi stać.
7.
2007 07 13, 09:12:09
Bzdura, nie musi stać. Wystarczy że svnserve będzie można uruchomić na zdalnym shellu.
8.
2007 07 13, 09:13:20
Ale czy to nie oznacza postawienia serwera i otwarcia zdalnego portu? No i wymaga dostępu do shella
9.
2007 07 13, 09:25:06
Postawienie serwera SSH – tak

A co do shella to pisałem
10.
2007 07 13, 09:27:18
Racja
Chodziło mi bardziej o to, że dla dozzie’go uruchomienie svnserve nie oznacza postawienia serwera svn..
11.
2007 07 13, 09:29:28
Polecam: http://svnbook.red-bean.com/en/1.2/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.sshauth
12.
2007 07 13, 09:31:24
O. Faktycznie. No to zwracam dozziemu honor
Najważniejsze zdanie to chyba
Zawsze mi się wydawało, że to wymaga postawienia serwera. Sam używałem tylko dostępu svn:// (w firmie też go stosujemy) i nie zagłębiałem się w materię svn+ssh://. Dzięki za sprostowanie!13.
2007 07 14, 13:31:50
Napisałem tutorial o tym jak można używać Git i Bazaar z Subversion. Jeżeli miałbyś jakieś uwagi, byłbym wdzięczny!
Dodaj komentarz: