12
07
2007
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
> 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.
Ale to oznacza, że rozmiar repo jest większy niż w systemach gdzie przechowuje się delty/diffy, tak?
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
Smox
A Mercurial jest taki szybki bo najważniejsze rzeczy ma napisane C 
Bazaar to bardzo fajny system i naprawdę prężnie się rozwija!
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 
Niestety tak się nie do końca da. Po SSH i owszem, ale to musi być protokół svn+ssh:// – zatem serwer SVNowy musi stać.
Bzdura, nie musi stać. Wystarczy że svnserve będzie można uruchomić na zdalnym shellu.
Ale czy to nie oznacza postawienia serwera i otwarcia zdalnego portu? No i wymaga dostępu do shella
Postawienie serwera SSH – tak
A co do shella to pisałem
Racja
Chodziło mi bardziej o to, że dla dozzie’go uruchomienie svnserve nie oznacza postawienia serwera svn..
Polecam: http://svnbook.red-bean.com/en/1.2/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.sshauth
O. Faktycznie. No to zwracam dozziemu honor Najważniejsze zdanie to chyba
The important thing to understand here is that the Subversion client is not connecting to a running svnserve daemonZawsze 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!
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!