Jakie są względne mocne i słabe strony Git, Mercurial i Bazaar? [Zamknięte]

Co ludzie tutaj postrzegają jako względne mocne i słabe strony Git, Mercurial i Bazaar?

Jakie kwestie należy wziąć pod uwagę, rozważając każdy z nich ze sobą i porównując je z systemami kontroli wersji, takimi jak SVN i Perforce?

Jakie czynniki wziąłbyś pod uwagę podczas planowania migracji z SVN do jednego z tych rozproszonych systemów kontroli wersji?

Git jest bardzo szybki, bardzo dobrze skaluje się i bardzo przejrzyście przedstawia swoje koncepcje. Wadą tego jest to, że ma stosunkowo stromą krzywą uczenia się. Dostępny jest port Win32, ale nie jest to obywatel pierwszej klasy. Git udostępnia użytkownikom skróty jako numery wersji; zapewnia to gwarancje (w tym, że pojedynczy skrót zawsze odnosi się do dokładnie tej samej treści; osoba atakująca nie może modyfikować historii bez wykrycia), ale może być uciążliwa dla użytkownika. Git ma unikalną koncepcję śledzenia zawartości plików, nawet gdy ta zawartość przenosi się między plikami i wyświetla pliki jako obiekty pierwszego poziomu, ale nie śledzi katalogów. Innym problemem związanym z git jest to, że ma wiele operacji (takich jak rebase), które ułatwiają modyfikowanie historii (w pewnym sensie - treść, do której odwołuje się hash, nigdy się nie zmieni, ale odniesienia do tego hasha mogą zostać utracone); niektórym purystom (łącznie ze mną) to się nie podoba.

Bazaar jest dość szybki (bardzo szybki w przypadku drzew z płytką historią, ale obecnie słabo skaluje się z długością historii) i jest łatwy do nauczenia dla osób zaznajomionych z interfejsami wiersza poleceń tradycyjnych SCM (CVS, SVN itp.). Win32 jest uważany przez zespół programistów za cel pierwszej klasy. Ma architekturę umożliwiającą podłączanie różnych komponentów i często zastępuje format pamięci; pozwala im to na wprowadzanie nowych funkcji (takich jak lepsza obsługa integracji z systemami kontroli wersji opartymi na różnych koncepcjach) i poprawę wydajności. Zespół Bazaar rozważa śledzenie katalogów i obsługę zmiany nazwy o najwyższej funkcjonalności. Podczas gdy globalnie unikatowe identyfikatory wersji są dostępne dla wszystkich wersji, revnos lokalne drzewa (standardowe numery wersji, bardziej zbliżone do tych używanych przez svn lub inne bardziej konwencjonalne SCM) są używane zamiast skrótów zawartości do identyfikowania wersji. Bazaar obsługuje „lekkie kasy”, w których historia jest przechowywana na zdalnym serwerze zamiast kopiowania do lokalnego systemu i jest automatycznie odwoływana w sieci w razie potrzeby; obecnie jest to unikalne wśród DSCM.

Oba mają dostępną jakąś formę integracji SVN; jednakże bzr-svn jest znacznie bardziej wydajny niż git-svn, głównie ze względu na wprowadzone w tym celu zmiany formatu zaplecza. [Aktualizacja, stan na 2014 r .: komercyjny produkt innej firmy SubGit zapewnia dwukierunkowy interfejs między SVN i Git, który jest porównywalny pod względem wierności z bzr-svn i znacznie bardziej dopracowany; Ja zdecydowanie polecam jego stosowanie nad tym z git-svn, gdy budżet i ograniczenia licencyjne pozwalają].

Nie korzystałem zbytnio z Mercurial, więc nie mogę komentować go szczegółowo - z wyjątkiem uwagi, że podobnie jak Git, ma adresowanie skrótów zawartości dla poprawek; podobnie jak Git, nie traktuje katalogów jako obiektów pierwszej klasy (i nie może przechowywać pustego katalogu). Jest jednak szybszy niż jakikolwiek inny DSCM z wyjątkiem Git i ma znacznie lepszą integrację z IDE (szczególnie dla Eclipse) niż którykolwiek z jego konkurentów. Biorąc pod uwagę jego charakterystykę wydajności (która jest tylko nieznacznie w tyle za Git) i jego doskonałe wsparcie dla wielu platform i IDE, Mercurial może być atrakcyjny dla zespołów ze znaczną liczbą członków zorientowanych na win32 lub IDE.

Jedną z obaw związanych z migracją z SVN jest to, że interfejsy GUI SVN i integracja z IDE są bardziej dojrzałe niż w przypadku dowolnego z rozproszonych SCM. Ponadto, jeśli obecnie intensywnie korzystasz z automatyzacji skryptów przed zatwierdzeniem za pomocą SVN (tj. Wymagasz przejścia testów jednostkowych przed zatwierdzeniem), prawdopodobnie będziesz chciał użyć narzędzia podobnego do PQM do automatyzacji żądań scalania do twoich współdzielonych gałęzi.

SVK to DSCM, który wykorzystuje Subversion jako magazyn zapasowy i ma całkiem dobrą integrację z narzędziami zorientowanymi na SVN. Ma jednak znacznie gorszą wydajność i skalowalność niż jakikolwiek inny główny DSCM (nawet Darcs) i należy go unikać w przypadku projektów, które mogą się rozrosnąć pod względem długości historii lub liczby plików.

[O autorze: Używam Git i Perforce do pracy, a Bazaar do moich osobistych projektów i jako wbudowana biblioteka; inne części organizacji mojego pracodawcy intensywnie korzystają z Mercurial. W poprzednim życiu zbudowałem wiele automatyzacji wokół SVN; Wcześniej mam doświadczenie z GNU Arch, BitKeeper, CVS i innymi. Na początku Git był dość odstręczający - wydawał się GNU Arch, ponieważ był środowiskiem wymagającym wielu koncepcji, w przeciwieństwie do zestawów narzędzi zbudowanych w celu dostosowania do wybranych przez użytkownika przepływów pracy - ale od tego czasu czuję się całkiem swobodnie z to].

Steve Streeting z projektu Ogre 3D właśnie (28.09.2009) opublikował na blogu wpis na ten temat, w którym robi świetne, wręcz ręczne porównanie Git, Mercurial i Bazaar .

W końcu odnajduje mocne i słabe strony ze wszystkimi trzema i bez wyraźnego zwycięzcy. Z drugiej strony daje świetny stół, który pomoże ci zdecydować, z którym chcesz się wybrać.

To krótka lektura i bardzo ją polecam.

Co ludzie tutaj postrzegają jako względne mocne i słabe strony Git, Mercurial i Bazaar?

Moim zdaniem mocną stroną Gita jest przejrzysta konstrukcja i bardzo bogaty zestaw funkcji. Uważam również, że jest to najlepsze wsparcie dla repozytoriów wielooddziałowych i zarządzania przepływami pracy z wieloma gałęziami. Jest bardzo szybki i ma mały rozmiar repozytorium.

Ma kilka przydatnych funkcji, ale przyzwyczajenie się do nich wymaga trochę wysiłku. Obejmują one widoczny pośredni ara (indeks) między obszarem roboczym a bazą danych repozytorium, co pozwala na lepszą rozdzielczość scalania w bardziej skomplikowanych przypadkach, inkrementalne comitting i comitting z brudnym drzewem; wykrywanie zmian nazw i kopii przy użyciu heurystyki podobieństwa zamiast śledzenia ich za pomocą jakiegoś rodzaju identyfikatorów plików, co działa dobrze i które pozwalają na obwinianie (dodawanie adnotacji), które może śledzić ruch kodu w plikach, a nie tylko hurtowe zmiany nazw.

Jedną z jego wad jest to, że obsługa MS Windows pozostaje w tyle i nie jest pełna. Inną dostrzeganą wadą jest to, że nie jest tak dobrze udokumentowany jak na przykład Mercurial i jest mniej przyjazny dla użytkownika niż konkurencja, ale się zmienia.

Moim zdaniem siła Mercuriala polega na jego dobrej wydajności i niewielkim rozmiarze repozytorium, w dobrym wsparciu dla MS Windows.

Główną wadą jest moim zdaniem fakt, że lokalne oddziały (wiele oddziałów w jednym repozytorium) są nadal obywatelami drugiej kategorii iw dziwny i skomplikowany sposób implementują tagi. Również sposób, w jaki radzi sobie ze zmianą nazw plików, był nieoptymalny (ale ta zmiana się zmieniła). Mercurial nie obsługuje połączeń ośmiornic (z więcej niż dwoma rodzicami).

Z tego, co słyszałem i czytałem, główne zalety Bazaar to łatwe wsparcie dla scentralizowanego przepływu pracy (co jest również wadą, ze scentralizowanymi koncepcjami widocznymi tam, gdzie nie powinno), śledzenie zmian nazw zarówno plików, jak i katalogów.

Jego główną wadą jest wydajność i rozmiar repozytorium dla dużych repozytoriów z długą nieliniową historią (wydajność poprawiła się przynajmniej dla niezbyt dużych repozytoriów), fakt, że domyślnym paradygmatem jest jedno ranczo na repozytorium (można jednak ustawić udostępnianie danych) i scentralizowane koncepcje (ale to także z tego, co słyszałem).

Git jest napisany w C, skryptach powłoki i Perlu, i można go używać skryptów; Mercurial jest napisany w C (rdzeń, dla wydajności) i Pythonie i zapewnia API dla rozszerzeń; Bazaar jest napisany w Pythonie i zapewnia API dla rozszerzeń.

Jakie kwestie należy wziąć pod uwagę, rozważając każdy z nich ze sobą i porównując je z systemami kontroli wersji, takimi jak SVN i Perforce?

Systemy kontroli wersji, takie jak Subversion (SVN), Perforce czy ClearCase, to scentralizowane systemy kontroli wersji. Git, Mercurial, Bazaar (a także Darcs, Monotone i BitKeeper) to rozproszone systemy kontroli wersji. Rozproszone systemy kontroli wersji pozwalają na znacznie szerszy zakres przepływów pracy. Pozwalają na użycie opcji „opublikuj gdy gotowe”. Mają lepszą obsługę rozgałęziania i scalania oraz przepływów pracy z wieloma gałęziami. Nie musisz ufać ludziom, którzy mają dostęp do zobowiązań, aby móc w łatwy sposób uzyskać od nich wkład.

Jakie czynniki wziąłbyś pod uwagę podczas planowania migracji z SVN do jednego z tych rozproszonych systemów kontroli wersji?

Jednym z czynników, które warto rozważyć, jest wsparcie dla inetract z SVN; Git ma git-svn, Bazaar ma bzr-svn, a Mercurial ma rozszerzenie hgsubversion.

Zastrzeżenie: Jestem użytkownikiem Git i drobnym współpracownikiem i oglądam (i uczestniczę) na liście mailingowej git. Znam Mercurial i Bazaar tylko z ich dokumentacji, rozmaitych dyskusji na IRC i list mailingowych oraz postów na blogach i artykułów porównujących różne systemy kontroli wersji (z których niektóre są wymienione na stronie GitComparison na Git Wiki).

InfoQ ma fajne porównanie .

Mercurial i Bazaar bardzo przypominają siebie na powierzchni. Oba zapewniają podstawową rozproszoną kontrolę wersji, tak jak w przypadku zatwierdzania offline i scalania wielu gałęzi, oba są napisane w Pythonie i oba są wolniejsze niż git. Istnieje wiele różnic po zagłębieniu się w kod, ale w przypadku rutynowych codziennych zadań są one w rzeczywistości takie same, chociaż Mercurial wydaje się mieć nieco większy rozmach.

Git, cóż, nie jest dla niewtajemniczonych. Jest znacznie szybszy niż Mercurial i Bazaar i został napisany do zarządzania jądrem Linuksa. Jest najszybszy z całej trójki i jest też z nich najpotężniejszy, ze sporym marginesem. Narzędzia do manipulacji dziennikiem i zatwierdzeniami Git są niezrównane. Jednak jest to również najbardziej skomplikowane i najbardziej niebezpieczne w użyciu. Bardzo łatwo jest stracić zatwierdzenie lub zrujnować repozytorium, zwłaszcza jeśli nie rozumiesz wewnętrznego działania git.

Spójrz na porównanie przeprowadzone ostatnio przez twórców Pythona: http://wiki.python.org/moin/DvcsComparison . Wybrali Mercurial z trzech ważnych powodów:

Decyzja o wyborze Mercurial została podjęta z trzech ważnych powodów:

• Według małej ankiety programiści Pythona są bardziej zainteresowani używaniem Mercurial niż Bazaar czy Git.
• Mercurial został napisany w języku Python, co jest zgodne z tendencją python-dev do „jedzenia własnych testów”.
• Mercurial jest znacznie szybszy niż bzr (jest wolniejszy niż git, choć ze znacznie mniejszą różnicą).
• Mercurial jest łatwiejszy do nauczenia dla użytkowników SVN niż Bazaar.

(z http://www.python.org/dev/peps/pep-0374/ )

Firma Sun przeprowadziła ocenę git , Mercurial i Bazaar jako kandydatów do zastąpienia Sun Teamware VCS w bazie kodu Solaris. Wydało mi się to bardzo interesujące.

Bardzo ważną brakującą rzeczą na bazarze jest cp. Nie możesz mieć wielu plików o tej samej historii, jak w SVN, zobacz na przykład tutaj i tutaj . Jeśli nie planujesz używać cp, bzr jest świetnym (i bardzo łatwym w użyciu) zamiennikiem svn.

Przez jakiś czas korzystałem z Bazaar, który bardzo mi się podobał, ale były to tylko mniejsze projekty i nawet wtedy było dość powolne. Tak łatwy do nauczenia, ale nie super szybki. Jest to jednak bardzo platforma X.

Obecnie używam Gita, który bardzo mi się podoba, ponieważ wersja 1.6 uczyniła go znacznie bardziej podobnym do innych VCS pod względem używanych poleceń.

Myślę, że główne różnice w moim doświadczeniu w korzystaniu z DVCS są następujące:

1. Git ma najbardziej aktywną społeczność i często pojawiają się artykuły o Git
2. GitHub naprawdę rządzi . Launchpad.net jest w porządku, ale nie przypomina przyjemności z Github
3. Liczba narzędzi przepływu pracy dla Git była świetna. Jest zintegrowany w każdym miejscu. Jest kilka dla Bzr, ale nie tak dużo lub nie tak dobrze utrzymanych.

Podsumowując, Bzr był świetny, kiedy wycinałem zęby na DVCS, ale teraz jestem bardzo zadowolony z Git i Github.

To jest duże pytanie, które zależy w dużej mierze od kontekstu, a wpisanie tekstu w jednym z tych małych pól tekstowych zajęłoby dużo czasu. Ponadto wszystkie trzy wydają się zasadniczo podobne, gdy są używane do zwykłych czynności wykonywanych przez większość programistów, więc nawet zrozumienie różnic wymaga dość ezoterycznej wiedzy.

Prawdopodobnie uzyskasz znacznie lepsze odpowiedzi, jeśli uda ci się przerwać analizę tych narzędzi do punktu, w którym będziesz mieć bardziej szczegółowe pytania.

Bazar jest IMHO łatwiejszy do nauczenia niż git. Git ma niezłe wsparcie na github.com.

Myślę, że powinieneś spróbować użyć obu i zdecydować, który najbardziej Ci odpowiada.

Co ludzie tutaj postrzegają jako względne mocne i słabe strony Git, Mercurial i Bazaar?

To bardzo otwarte pytanie, graniczące z przynętą na płomień.

Git jest najszybszy, ale wszystkie trzy są wystarczająco szybkie. Bazaar jest najbardziej elastyczny (ma przejrzystą obsługę odczytu i zapisu dla repozytoriów SVN) i bardzo dba o wygodę użytkownika. Mercurial jest gdzieś pośrodku.

Wszystkie trzy systemy mają wielu fanów. Osobiście jestem fanboyem Bazaar.

Jakie kwestie należy wziąć pod uwagę, rozważając każdy z nich ze sobą i porównując je z systemami kontroli wersji, takimi jak SVN i Perforce?

Te pierwsze to systemy rozproszone. Te ostatnie to systemy scentralizowane. Ponadto Perforce jest prawnie zastrzeżony, podczas gdy wszystkie inne są wolne, jak w mowie .

Scentralizowany kontra zdecentralizowany to znacznie ważniejszy wybór niż którykolwiek z systemów, o których wspomniałeś w swojej kategorii.

Jakie czynniki wziąłbyś pod uwagę podczas planowania migracji z SVN do jednego z tych rozproszonych systemów kontroli wersji?

Po pierwsze, brak dobrego substytutu TortoiseSVN. Chociaż Bazaar pracuje nad własnym wariantem żółwia , ale jeszcze go nie ma, stan na wrzesień 2008.

Następnie szkolenie kluczowych osób w zakresie tego, jak korzystanie ze zdecentralizowanego systemu wpłynie na ich pracę.

Wreszcie integracja z resztą systemu, na przykład trackery problemów, nocny system kompilacji, automatyczny system testów itp.

Twoim głównym problemem będzie to, że są to rozproszone SCM i jako takie wymagają niewielkiej zmiany w sposobie myślenia użytkownika. Gdy ludzie przyzwyczają się do tego pomysłu, szczegóły techniczne i wzorce użytkowania będą na miejscu, ale nie lekceważ tej początkowej przeszkody, szczególnie w środowisku korporacyjnym. Pamiętaj, wszystkie problemy to problemy ludzi.

ddaa.myopenid.com wspomniał o tym mimochodem, ale myślę, że warto jeszcze raz wspomnieć: Bazaar może czytać i pisać do zdalnych repozytoriów SVN. Oznacza to, że możesz użyć Bazaar lokalnie jako dowód słuszności koncepcji, podczas gdy reszta zespołu nadal używa Subversion.

EDYCJA: Prawie wszystkie narzędzia mają teraz jakiś sposób interakcji z SVN, ale teraz mam osobiste doświadczenie, które git svndziała bardzo dobrze. Używam go od miesięcy, z minimalnymi czkawkami.

Na git jest dobre wideo Linusa Torvaldsa. Jest twórcą Gita, więc to właśnie promuje, ale w filmie wyjaśnia, czym są rozproszone SCM i dlaczego są lepsze od scentralizowanych. Istnieje wiele porównań git (mercurial jest uważany za OK) i cvs / svn / perforce. Pojawiają się również pytania od publiczności dotyczące migracji do rozproszonego SCM.

Uważam, że ten materiał jest pouczający i zostałem sprzedany do rozproszonego SCM. Ale pomimo wysiłków Linusa mój wybór jest ryzykowny. Powodem jest bitbucket.org, uważam, że jest lepszy (bardziej hojny) niż github.

Muszę tutaj powiedzieć ostrzeżenie: Linus ma dość agresywny styl, myślę, że chce być zabawny, ale ja się nie śmiałem. Poza tym wideo jest świetne, jeśli jesteś nowy w rozproszonych SCM i myślisz o przejściu z SVN.

http://www.youtube.com/watch?v=4XpnKHJAok8

Rozproszone systemy kontroli wersji (DVCS) rozwiązują inne problemy niż scentralizowane systemy VCS. Porównywanie ich jest jak porównywanie młotków i śrubokrętów.

Scentralizowane systemy VCS są projektowane z myślą, że istnieje Jedno Prawdziwe Źródło, które jest Błogosławione, a zatem Dobre. Wszyscy programiści pracują (wypisują) z tego źródła, a następnie dodają (zatwierdzają) swoje zmiany, które następnie stają się podobnie Błogosławione. Jedyną prawdziwą różnicą między CVS, Subversion, ClearCase, Perforce, VisualSourceSafe i wszystkimi innymi CVCS jest przepływ pracy, wydajność i integracja oferowana przez każdy produkt.

Rozproszone systemy VCS są projektowane z myślą o tym, aby jedno repozytorium było tak samo dobre, jak inne, a łączenie się z jednego repozytorium w drugie to tylko kolejna forma komunikacji. Każda wartość semantyczna dotycząca tego, któremu repozytorium należy zaufać, jest narzucana z zewnątrz przez proces, a nie przez samo oprogramowanie.

Prawdziwy wybór między użyciem jednego lub drugiego typu jest organizacyjny - jeśli Twój projekt lub organizacja wymaga scentralizowanej kontroli, to DVCS nie jest starterem. Jeśli od twoich programistów oczekuje się pracy w całym kraju / świecie, bez bezpiecznych połączeń szerokopasmowych z centralnym repozytorium, to DVCS jest prawdopodobnie Twoim zbawieniem. Jeśli potrzebujesz obu, masz fsck.