A tak przy okazji, chciałbym zobaczyć procent wykorzystania różnych systemów DVCS.
sergiol
Odpowiedzi:
145
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].
Hej. Chcę tylko, żebyś wiedział, że cscvs jest nadal używany do uruchamiania importu kodu Launchpad, a kiedy tam pracowałem, wydałem wersję Canonical.
ddaa,
19
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ć.
@gavenkoa, bazar jest intuicyjny dla osób pochodzących z SVN. Jeśli pochodzisz z gita, masz model mentalny, który jest bliższy podstawom bazaru, ale bardzo, bardzo daleko od jego interfejsu. (... posiadanie tak grubej warstwy abstrakcji między podkładami a interfejsem jest tym, co sprawia, że bzr może być przyjazny dla osób zaznajomionych z modelem SVN).
Charles Duffy,
2
@CharlesDuffy Mercurial ma również intuicyjne nazwy poleceń i nie jest martwy (rozwój Bazaar został zatrzymany 2 lata temu i firma Canonical go odrzuciła, tak Git + github wygrywa grę DVCS ). Nigdy nie rozumiem schematu nazewnictwa git, więc osobiście wolę HG. Trudno jest walczyć z chłopakami, którzy
kochają
@gavenkoa, podstawowe nazwy poleceń bzr pasują do SVN, więc znowu nie widzę, co mogłoby być w nich nieintuicyjne (dla użytkownika SVN). Tak, oczywiście, rozwój umarł. Nie twierdzę, że bzr jest praktyczny w użyciu - tylko, że konkretna krytyka była poza bazą.
Charles Duffy,
1
@gavenkoa ... ja również były znane bronić aspekty BitKeepera, pomimo dość dużą urazę programistów Oprogramowania / właściciele (jego podstawą publicznie udokumentowane ... choć Larry nie nazywają mnie raz do opisania tego, co ich koniec się stało i przyznaję, że rozumiem teraz obie strony). Tylko dlatego, że bronię SCM, nie oznacza, że faktycznie zalecam, aby ludzie go używali. :)
Charles Duffy
15
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).
FYI - bzr-svn jest o wiele bardziej zdolny niż git-svn, ponieważ jest dwukierunkowy: mogę uruchomić "bzr branch svn: // ...", a później scalić moje zmiany z powrotem na serwer svn - gdzie one będą przechowywane z metadanymi, które rozpoznają inni klienci bzr.
Charles Duffy
2
Jestem programistą hg i przyglądałem się trochę projektowi Git. Cieszę się, że obaj traktują historię w jedyny rozsądny sposób dla ustawień rozproszonych: na wysokim poziomie są one zarówno acyklicznym wykresem zatwierdzeń, a na niższym pozwalają na zatwierdzanie manifestów referencyjnych, które odwołują się do plików (blobów w Git ). Mercurial ma anonimowe gałęzie (których AFAIK nie istnieje w Git), ma gałęzie z zakładkami (bardzo podobne do gałęzi Git, ale bez push / pull) i ma nazwane gałęzie (nazwa gałęzi jest zapisywana w zatwierdzeniu - te też nie są w Git).
Ta odpowiedź byłaby poprawiona przez podsumowanie wspomnianego porównania.
lindes,
7
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.
Mercurial jest naprawdę na równi z Git. Wydajność nie jest dużą różnicą. Ale bazar jest po prostu wolniejszy niż Mercurial i Git.
Joshua Partogi
@jpartogi - Wyniki firmy Bazaar poprawiały się znacznie szybciej niż jego konkurenci, więc byłbym ostrożny, robiąc tego rodzaju stwierdzenia - szczególnie w przypadku refaktoryzacji pamięci, która jest dostępna jako wersja zapoznawcza w bieżących wersjach i ma stać się domyślną w 2.0.
Z tego samego powodu Mozilla i Sun również używają Mercurial.
Joshua Partogi
2
bzr jest również napisany w Pythonie, jest rzeczywiście wolniejszy niż hg, ale dzięki szybko zawężającemu się marginesowi - i jako użytkownik zarówno Bazaar, jak i Mercurial, / zdecydowanie / nie zgadzam się z twierdzeniem „łatwiejsze do nauczenia”.
Charles Duffy
1
Wszystkie wciąż się rozwijają. Zdecydowałem się na Bazaar na DCVS na początek, ponieważ myślałem, że jest to najłatwiejsze (ale niewiele w tym) i Launchpad.net. To było dość powolne. Git na OSX wydaje się w porządku, ale słaba obsługa systemu Windows. Ponieważ projekty Python i Google przyjęły go teraz, a ze względu na TortoiseHg przechodzę na Mercurial. Myślę, że Mercurial zyskuje masę krytyczną nad Bazarem i będzie tam. A Git zrobi swoje, zawsze koncentrując się na Posix, więc nigdy nie będzie naprawdę dominujący.
Nick
5
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.
te oceny są nieco nieaktualne, nowsze wersje zmieniły niektóre z przedstawionych tam wad.
hayalci
2
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.
Brakuje tego z projektu - cp nie może zostać dodany bez tworzenia wielu przypadków, w których trudno lub niemożliwe jest upewnienie się, że wykonasz właściwą rzecz przy scalaniu gałęzi, w której nastąpiła kopia i zmiany, z inną gałęzią ze zmianami, ale bez kopii .
Charles Duffy,
Jasne, ale należy o tym pamiętać - i byłaby to bardzo przydatna funkcja w wielu przypadkach użycia (np. Podzielenie pliku na dwa różne i zachowanie historii dla obu). Właściwie jest to jedyny powód, dla którego nadal używam subversion w niektórych projektach - gdzie scalanie jest nieistotne, ale kopiowanie nie
Davide,
2
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:
Git ma najbardziej aktywną społeczność i często pojawiają się artykuły o Git
GitHub naprawdę rządzi . Launchpad.net jest w porządku, ale nie przypomina przyjemności z Github
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.
Masz na myśli „teraz” bardzo szczęśliwy, w przeciwieństwie do „nie” bardzo szczęśliwy, prawda?
Charles Duffy,
Dzięki Charles!
Ugryź
1
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.
Mercurial jest tak prosty jak Bazaar, stosunkowo szybki w porównaniu do git i ma niezłe wsparcie na Bitbucket. Więc o co jeszcze możesz zapytać?
Joshua Partogi
1
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.
Dla przypomnienia, na bieżącej stronie czytamy: „Od wersji Bazaar 1.6, TortoiseBZR jest zawarty w oficjalnym instalatorze”, więc wydaje się, że dojrzał.
PhiLho
1
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.
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.
Istnieją bardzo istotne różnice między CVS, SVN i VisualSourceSafe (żeby wymienić tylko 3), które mają poważny wpływ na ich użyteczność - i nie są to tylko problemy z przepływem pracy i / lub integracją.
Murph
Użyłem wszystkich trzech i technicznie rzecz biorąc, masz rację, ale z wysokiego poziomu moja odpowiedź jest również ważna. Kontrola wersji dla więcej niż jednego programisty to narzędzie organizacyjne; o ile narzędzie spełnia potrzeby organizacji, na dłuższą metę tylko to się liczy.
Odpowiedzi:
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].
źródło
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.
źródło
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ń.
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.
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).
źródło
InfoQ ma fajne porównanie .
źródło
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.
źródło
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:
źródło
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.
źródło
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.
źródło
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:
Podsumowując, Bzr był świetny, kiedy wycinałem zęby na DVCS, ale teraz jestem bardzo zadowolony z Git i Github.
źródło
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.
źródło
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.
źródło
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.
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.
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.
źródło
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.
źródło
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.źródło
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
źródło
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.
źródło