Staram się zrozumieć zalety rozproszonego systemu kontroli wersji (DVCS).

Znalazłem Subversion reedukacji i ten artykuł przez Martin Fowler bardzo przydatne.

Mercurial i inne DVCS promują nowy sposób pracy nad kodem za pomocą zestawów zmian i lokalnych zatwierdzeń. Zapobiega łączeniu piekła i innych problemów ze współpracą

Nie ma na nas wpływu, ponieważ ćwiczę ciągłą integrację i praca w oddziale prywatnym nie jest opcją, chyba że eksperymentujemy. Używamy gałęzi do każdej głównej wersji, w której naprawiamy błędy scalone z pnia.

Mercurial pozwala mieć poruczników

Rozumiem, że może to być przydatne w przypadku bardzo dużych projektów, takich jak Linux, ale nie widzę wartości w małych i wysoce współpracujących zespołach (od 5 do 7 osób).

Mercurial jest szybszy, zajmuje mniej miejsca na dysku, a pełna kopia lokalna pozwala na szybsze operacje na logach i różnicach.

Nie martwię się tym, ponieważ nie zauważyłem problemów z prędkością lub przestrzenią w SVN, nawet przy bardzo dużych projektach, nad którymi pracuję.

Szukam twoich osobistych doświadczeń i / lub opinii od byłych maniaków SVN. Zwłaszcza jeśli chodzi o koncepcję zestawu zmian i ogólny wzrost wydajności, który zmierzyłeś.

AKTUALIZACJA (12 stycznia) : Jestem teraz przekonany, że warto spróbować.

AKTUALIZACJA (12 czerwca) : Pocałowałem Mercurial i podobało mi się. Smak jego wiśniowych lokalnych zobowiązań. Pocałowałem Mercurial, żeby tego spróbować. Mam nadzieję, że mój serwer SVN nie ma nic przeciwko. Czułem się tak źle. Czułam się tak dobrze. Nie znaczy, że jestem dziś zakochany .

KOŃCOWA AKTUALIZACJA (29 lipca) : Miałem zaszczyt przejrzeć kolejną książkę Erica Sink pod nazwą Kontrola wersji przez przykład . Skończył mnie przekonać. Pójdę po Mercurial.

Uwaga: Zobacz „EDYCJA”, aby uzyskać odpowiedź na bieżące pytanie

Przede wszystkim przeczytaj Subversion Re-education Joela Spolsky'ego. Myślę, że na większość twoich pytań tam znajdziesz odpowiedź.

Kolejna rekomendacja, wykład Linusa Torvaldsa na Git: http://www.youtube.com/watch?v=4XpnKHJAok8 . Ten drugi może również odpowiedzieć na większość twoich pytań i jest to dość zabawne.

BTW, coś, co uważam za dość zabawne: nawet Brian Fitzpatrick i Ben Collins-Sussman, dwóch oryginalnych twórców subwersji, powiedział w jednym z rozmów Google „przepraszam za to”, odnosząc się do subwersji gorszej od merkurialnej (i ogólnie DVCS).

Teraz, IMO i ogólnie, dynamika zespołu rozwija się bardziej naturalnie z każdym DVCS, a wyjątkową korzyścią jest to, że możesz dokonywać zleceń offline, ponieważ implikuje następujące rzeczy:

• Nie zależy od serwera i połączenia, co oznacza szybsze czasy.
• Nie będąc niewolnikiem miejsc, w których można uzyskać dostęp do Internetu (lub VPN) tylko po to, aby móc się zobowiązać.
• Każdy ma kopię zapasową wszystkiego (plików, historii), nie tylko serwer. Oznacza to, że każdy może zostać serwerem .
• Możesz zobowiązać się kompulsywnie, jeśli chcesz, bez zakłócania kodu innych użytkowników . Zatwierdzenia są lokalne. Zobowiązując się, nie stąpacie sobie po palcach. Nie psujesz kompilacji ani środowisk innych tylko przez zaangażowanie.
• Osoby bez „dostępu do zatwierdzania” mogą zatwierdzać (ponieważ zatwierdzanie w DVCS nie oznacza przesyłania kodu), obniżając barierę dla wkładów, możesz zdecydować o wycofaniu ich zmian lub nie jako integrator.
• Może wzmocnić naturalną komunikację, ponieważ DVCS sprawia, że ​​jest to niezbędne ... w zamian za to, co masz, to zatwierdzanie ras, które wymuszają komunikację, ale utrudniają twoją pracę.
• Współtwórcy mogą tworzyć zespoły i obsługiwać własne scalanie, co oznacza mniej pracy dla integratorów.
• Współtwórcy mogą mieć własne oddziały bez wpływu na innych (ale w razie potrzeby mogą je udostępniać).

O twoich punktach:

• Scalanie piekła nie istnieje w DVCSland; nie trzeba się tym zajmować. Zobacz następny punkt .
• W DVCS każdy reprezentuje „gałąź”, co oznacza, że ​​połączenia są za każdym razem, gdy wprowadzane są zmiany. Nazwane gałęzie to kolejna sprawa.
• Jeśli chcesz, możesz nadal korzystać z ciągłej integracji. Nie jest to konieczne IMHO, po co dodawać złożoności? Po prostu kontynuuj testowanie w ramach swojej kultury / polityki.
• Mercurial jest szybszy w niektórych rzeczach, git jest szybszy w innych. W zasadzie nie zależy to od DVCS, ale od ich konkretnych implementacji AFAIK.
• Każdy zawsze będzie miał pełny projekt, nie tylko ty. Rozproszona rzecz ma związek z tym, że możesz zatwierdzać / aktualizować lokalnie, udostępnianie / pobieranie z komputera nazywa się pchaniem / ciągnięciem.
• Ponownie przeczytaj Ponowną edukację Subversion. DVCS są łatwiejsze i bardziej naturalne, ale różnią się, nie próbuj myśleć, że cvs / svn === jest podstawą wszystkich wersji.

Włączyłem trochę dokumentacji do projektu Joomla, aby pomóc w głoszeniu migracji do DVCS, i tutaj zrobiłem kilka diagramów ilustrujących scentralizowane vs rozproszone.

Scentralizowane

Rozpowszechniany w praktyce ogólnej

Rozłożone w pełni

Widzicie na diagramie, że wciąż istnieje „scentralizowane repozytorium”, a to jeden z ulubionych argumentów fanów scentralizowanej wersji: „nadal jesteś scentralizowany”, a nie, nie jesteś, ponieważ „scentralizowane” repozytorium to tylko repozytorium wszyscy zgadzają się na (np. oficjalne repozytorium github), ale może się to zmienić w dowolnym momencie.

Jest to typowy przepływ pracy w projektach typu open source (np. Projekt o dużej współpracy) z wykorzystaniem DVCS:

Bitbucket.org jest w pewnym sensie odpowiednikiem github dla merkurialu, wiedz, że mają nieograniczone prywatne repozytoria z nieograniczoną przestrzenią, jeśli twój zespół jest mniejszy niż pięć, możesz użyć go za darmo.

Najlepszym sposobem, aby przekonać się do korzystania z DVCS, jest wypróbowanie DVCS, każdy doświadczony programista DVCS, który używał svn / cvs, powie ci, że warto i że nie wiedzą, jak przetrwali bez niego cały czas.

EDYCJA : Aby odpowiedzieć na drugą edycję, mogę tylko powtórzyć, że z DVCS masz inny przepływ pracy, radzę nie szukać powodów, aby nie wypróbować go z powodu najlepszych praktyk , to tak, jakby ludzie twierdzili, że OOP nie jest konieczne, ponieważ potrafią obejść złożone wzorce projektowe za pomocą tego, co zawsze robią z paradygmatem XYZ; i tak możesz skorzystać.

Wypróbuj, a zobaczysz, jak praca w „oddziale prywatnym” jest rzeczywiście lepszą opcją. Jednym z powodów, dla których mogę powiedzieć, dlaczego ta ostatnia jest prawdziwa, jest to, że tracisz strach przed popełnieniem , pozwalając ci popełnić w dowolnym momencie, kiedy uznasz to za stosowne i działa w bardziej naturalny sposób.

Jeśli chodzi o „łączenie piekła”, mówicie „chyba, że ​​eksperymentujemy”, mówię „nawet jeśli eksperymentujecie + zachowując + pracując jednocześnie w odnowionej wersji 2.0 ”. Jak mówiłem wcześniej, piekło nie istnieje, ponieważ:

• Za każdym razem, gdy zatwierdzasz, generujesz nienazwaną gałąź i za każdym razem, gdy twoje zmiany spełniają zmiany innych osób, następuje naturalne scalenie.
• Ponieważ DVCS zbierają więcej metadanych dla każdego zatwierdzenia, podczas łączenia występuje mniej konfliktów ... więc można nawet nazwać to „inteligentnym scaleniem”.
• Kiedy wpadasz na konflikty scalania, możesz użyć tego:

Poza tym rozmiar projektu nie ma znaczenia, kiedy przerzuciłem się z subwersji, faktycznie widziałem już korzyści podczas pracy w pojedynkę, wszystko było w porządku. Do Zestawienia zmian (nie dokładnie wersji, ale specyficzny zestaw zmian dla konkretnych plików, które obejmują popełnić, odizolowane od stanu kodzie) pozwalają wizualizować dokładnie to, co masz na myśli robiąc to, co robiłeś do konkretnej grupy plików, nie cała baza kodów.

Odnośnie sposobu działania zestawów zmian i zwiększenia wydajności. Spróbuję to zilustrować przykładem, który chciałbym podać: przełącznik projektu mootools z svn zilustrowany na ich grafie sieciowym github .

Przed

Po

To, co widzisz, to to, że programiści mogą skoncentrować się na własnej pracy podczas uruchamiania, bez obawy przed złamaniem kodu innych, martwią się o złamanie kodu innych po wypchnięciu / wyciągnięciu (DVCS: najpierw zatwierdzenie, następnie push / pull, a następnie aktualizacja ), ale ponieważ scalanie jest tutaj mądrzejsze, często nigdy nie robią ... nawet jeśli występuje konflikt scalania (co jest rzadkie), spędzasz tylko 5 minut lub mniej na naprawie.

Radzę ci poszukać kogoś, kto wie, jak używać mercurial / git i powiedzieć mu, żeby wyjaśnił ci to. Spędzając około pół godziny z kilkoma przyjaciółmi w wierszu poleceń, używając mercurial na naszych komputerach stacjonarnych i kontach bitbucket, pokazując im, jak się łączyć, a nawet wymyślając konflikty, aby zobaczyć, jak naprawić w absurdalnie dużej ilości czasu, byłem w stanie pokazać im prawdziwa moc DVCS.

Na koniec, polecam ci użycie mercurial + bitbucket zamiast git + github, jeśli pracujesz z Windowsem. Mercurial jest również nieco prostszy, ale git jest potężniejszy do bardziej złożonego zarządzania repozytorium (np. Git rebase ).

Niektóre dodatkowe zalecane odczyty:

• Rozproszone systemy kontroli wersji: Git vs. Mercurial vs. SVN
• Git vs. Mercurial: Proszę się zrelaksować
• Rozproszona kontrola wersji i Git [Część 1] oraz Rozproszona kontrola wersji i Git [Część 2]
• Git / Mercurial vs. Subversion: Fight!
• DVCS vs Subversion smackdown, runda 3
• Dlaczego lubię Mercurial bardziej niż Git ( część 1 , część 2 )
• Współdziałanie z Git: zmniejszenie tarcia współpracy Open Source z Git VCS
• „Jak do tej pory pracowały dla ciebie DVCS?” - post na Joomla! Lista dyskusyjna Framework Development z prośbą o opinie po eksperymentalnym przyjęciu mercurial i git dla Joomla! Projekt platformy
• Rozgałęzianie DVCS (z Mercurial) - szczegółowe i przykładowe wprowadzenie do tego, jak wygląda rozgałęzienie w DVCS, co jest prawdopodobnie najważniejszą funkcją w tych systemach

Mówisz między innymi, że jeśli zasadniczo pozostajesz w jednym oddziale, nie potrzebujesz rozproszonej kontroli wersji.

To prawda, ale czy nie jest to niepotrzebnie silne ograniczenie twojego sposobu pracy i takie, które nie skaluje się dobrze do wielu lokalizacji w wielu strefach czasowych? Gdzie powinien się znajdować centralny serwer subversion i czy wszyscy powinni iść do domu, jeśli ten serwer z jakiegoś powodu jest wyłączony?

DVCS to Subversion, a Bittorrent to ftp

(technicznie, nie legalnie). Być może, jeśli się nad tym zastanowisz, możesz zrozumieć, dlaczego jest to tak duży krok naprzód?

Dla mnie przejście na git natychmiast skutkowało

• Łatwiejsze jest tworzenie kopii zapasowych (wystarczy „zdalna aktualizacja” i gotowe)
• Łatwiejsze do wykonania małe kroki podczas pracy bez dostępu do centralnego repozytorium. Po prostu pracujesz i synchronizujesz po powrocie do sieci, w której znajduje się centralne repozytorium.
• Szybsze budowanie Hudsona. Znacznie szybsze użycie git pull niż aktualizacji.

Zastanów się, dlaczego Bittorrent jest lepszy niż ftp, i ponownie rozważ swoją pozycję :)

Uwaga: Wspomniano, że istnieją przypadki użycia, w których ftp jest szybszy niż bittorrent. Dzieje się tak w taki sam sposób, w jaki plik kopii zapasowej przechowywany przez ulubiony edytor jest szybszy w użyciu niż system kontroli wersji.

Zabójczą funkcją rozproszonych systemów kontroli wersji jest część rozproszona. Nie pobierasz „kopii roboczej” z repozytorium, klonujesz całą kopię repozytorium. Jest to ogromne, ponieważ zapewnia potężne korzyści:

• Możesz czerpać korzyści z kontroli wersji, nawet jeśli nie masz dostępu do Internetu, takiego jak ... Ten jest niestety nadużywany i nadmiernie przeciążony, ponieważ DVCS jest niesamowity - po prostu nie jest to mocny argument sprzedaży kodujemy się bez dostępu do Internetu tak często, jak zaczyna padać żaba.

• Prawdziwym powodem posiadania lokalnego repozytorium jest zabójca, ponieważ masz całkowitą kontrolę nad swoją historią zatwierdzeń, zanim zostanie ona wypchnięta do głównego repozytorium .

Naprawiono błąd i kończyło się na czymś takim:

r321 Fixed annoying bug.
r322 Argh, unexpected corner case to annoying bug in r321!
r323 Ok, really fixed corner case in r322
r324 Oops, forgot to remove some debugging code related to r321
...

I tak dalej. Taka historia jest niechlujna --- tak naprawdę była tylko jedna poprawka, ale teraz implementacja jest rozłożona na wiele zatwierdzeń zawierających niepożądane artefakty, takie jak dodawanie i usuwanie instrukcji debugowania. W przypadku systemu takiego jak SVN alternatywą jest nie zatwierdzanie (!!!), dopóki wszystko nie zadziała, aby utrzymać czystość historii. Nawet wtedy błędy mijają, a prawo Murphy'ego czeka cię brutalnie, gdy znaczna ilość pracy nie jest chroniona przez kontrolę wersji.

Posiadanie lokalnego klonu repozytorium, którego jesteś właścicielem , naprawia to, ponieważ możesz ponownie zapisywać historię, ciągle zmieniając „napraw to”, a „ups” zatwierdza zatwierdzenie „naprawy błędu”. Na koniec dnia jedno czyste zatwierdzenie zostaje wysłane do głównego repozytorium, które wygląda następująco:

r321 Fixed annoying bug.

Tak właśnie powinno być.

Możliwość ponownego zapisywania historii jest jeszcze większa w połączeniu z modelem rozgałęziającym. Deweloper może wykonać pracę całkowicie odizolowaną w gałęzi, a kiedy nadejdzie czas, aby przenieść tę gałąź do pnia, masz wiele ciekawych opcji:

• Wykonaj zwykłe połączenie wanilii . Przynosi wszystko w brodawki i tak dalej.

• Zrób rebase . Umożliwia przeglądanie historii oddziału, zmianę kolejności zatwierdzeń, wyrzucanie zatwierdzeń, łączenie zatwierdzeń razem, ponowne zapisywanie komunikatów zatwierdzeń --- nawet edytowanie zatwierdzeń lub dodawanie nowych! Rozproszony system kontroli wersji ma głębokie wsparcie dla przeglądu kodu.

Gdy dowiedziałem się, w jaki sposób lokalne repozytoria pozwoliły mi edytować moją historię ze względu na zdrowie psychiczne moich innych programistów i przyszłego siebie, zawiesiłem SVN na dobre. Mój klient Subversion jest teraz git svn.

Umożliwienie programistom i menedżerom sprawowania kontroli redakcyjnej nad historią zatwierdzania zapewnia lepszą historię projektu, a czysta historia do pracy naprawdę pomaga mojej produktywności jako programisty. Jeśli cała ta mowa o „przepisywaniu historii” cię przeraża, nie martw się, bo po to są repozytoria centralne, publiczne lub główne. Historia może (i powinna!) Zostać ponownie zapisana do momentu, w którym ktoś przeniesie ją do oddziału w repozytorium, z którego czerpią inni ludzie. W tym momencie historię należy traktować jak wyrytą na kamiennej tabliczce.

Odpowiedź dukofgamings jest prawdopodobnie tak dobra, jak to tylko możliwe, ale chcę podejść do tego z innego kierunku.

Załóżmy, że to, co mówisz, jest absolutnie prawdziwe i że stosując dobre praktyki możesz uniknąć problemów, które DVCS miał rozwiązać. Czy to oznacza, że ​​DVCS nie zapewni ci żadnej korzyści? Ludzie śmierdzą przestrzeganiem najlepszych praktyk. Ludzi będzie bałagan. Dlaczego więc miałbyś unikać oprogramowania zaprojektowanego do naprawy zestawu problemów, zamiast polegać na ludziach, którzy robią coś, co możesz przewidzieć z wyprzedzeniem, że nie zrobią tego?

Tak, to boli, gdy trzeba scalić duże zmiany w podwersji. Ale jest to również świetne doświadczenie edukacyjne, dzięki któremu robisz wszystko, co możliwe, aby uniknąć łączenia konfliktów. Innymi słowy, uczysz się często meldować . Wczesna integracja jest bardzo dobrą rzeczą dla każdego kolokowanego projektu. Tak długo, jak wszyscy to robią, używanie subwersji nie powinno stanowić większego problemu.

Git, na przykład, został zaprojektowany do pracy rozproszonej i zachęca ludzi do pracy nad własnymi projektami i tworzenia własnych widelców do (ewentualnego) scalenia później. To było nie specjalnie zaprojektowany do ciągłej integracji w „mały i bardzo współpracy zespołów”, która jest co OP prosi. Przeciwnie, pomyśl o tym. Nie będziesz mógł użyć jego fantazyjnych funkcji rozproszonych, jeśli wszystko, co robisz, to siedzenie w tym samym pokoju i wspólne działanie na tym samym kodzie.

Tak więc dla kolokowanego zespołu korzystającego z CI naprawdę nie sądzę, żeby miało to znaczenie, jeśli używasz systemu rozproszonego, czy nie. Sprowadza się do smaku i doświadczenia.

Ponieważ powinieneś stale kwestionować swoją wiedzę. Lubisz subwersję i rozumiem, ponieważ korzystałem z niej przez wiele lat i bardzo się z tego cieszyłem, ale to nie znaczy, że nadal jest to narzędzie, które najbardziej ci odpowiada.

Uważam, że kiedy zacząłem go używać, był to najlepszy wybór w tym czasie. Ale z czasem pojawiają się inne narzędzia i teraz wolę git, nawet do własnych projektów w wolnym czasie.

A subwersja ma pewne wady. Np. Jeśli zmienisz nazwę katalogu na dysku, to nie zostanie ona zmieniona w repozytorium. Przenoszenie plików nie jest obsługiwane, dlatego przenoszenie pliku jest operacją kopiowania / usuwania, co utrudnia scalanie zmian, gdy pliki zostały przeniesione / zmieniono ich nazwę. Śledzenie scalania nie jest tak naprawdę wbudowane w system, a raczej realizowane w postaci obejścia.

Git rozwiązuje te problemy (w tym automatyczne wykrywanie, czy plik został przeniesiony, nie musisz nawet mówić, że to fakt).

Z drugiej strony git nie pozwala na rozgałęzienie na poszczególnych poziomach katalogów, tak jak robi to Subversion.

Więc moja odpowiedź brzmi: powinieneś zbadać alternatywy, sprawdzić, czy lepiej pasuje do twoich potrzeb, niż to, co znasz, a następnie zdecydować.

Pod względem wydajności Git lub jakikolwiek inny DVCS ma dużą przewagę nad SVN, gdy musisz przełączać się z jednej gałęzi do drugiej lub przeskakiwać z jednej wersji do drugiej. Ponieważ wszystko jest przechowywane lokalnie, rzeczy są znacznie szybsze niż w przypadku SVN.

To samo może sprawić, że się przestawię!

Zamiast myśleć o tym, że „stosując najlepsze praktyki nie potrzebujesz DVCS”, dlaczego nie rozważyć, że przepływ pracy SVN to jeden przepływ pracy z jednym zestawem najlepszych praktyk, a przepływ pracy GIT / Hg to inny przepływ pracy, z innym zestawem najlepszych praktyk.

git bisect (i wszystkie jego konsekwencje dla twojego głównego repozytorium)

W Git bardzo ważną zasadą jest to, że można znaleźć błędy przy użyciu git bisect. Aby to zrobić, weź ostatnią uruchomioną wersję, o której wiadomo, że działa, i pierwszą uruchomioną wersję, o której wiadomo, że się nie powiedzie, i wykonaj (z pomocą Gita) wyszukiwanie binarne, aby dowiedzieć się, które zatwierdzenie spowodowało błąd. Aby to zrobić, cała historia zmian musi być względnie wolna od innych błędów, które mogą zakłócać wyszukiwanie błędów (wierzcie lub nie, to naprawdę działa całkiem dobrze w praktyce, a programiści jądra Linux robią to cały czas).

Aby osiągnąć tę git bisectfunkcję, opracowujesz nową funkcję w jej własnej gałęzi funkcji , zmieniasz jej podstawy i czyścisz historię (więc nie masz żadnych znanych niedziałających rewizji w swojej historii - po prostu kilka zmian, z których każda bierzesz udział w celu rozwiązania problemu), a następnie po zakończeniu funkcji scalasz ją z główną gałęzią z działającą historią.

Ponadto, aby to zadziałało, musisz zdyscyplinować, z której wersji głównego oddziału zaczynasz swoją gałąź funkcji. Nie możesz po prostu zacząć od obecnego stanu masteroddziału, ponieważ może to mieć niepowiązane błędy - więc rada w społeczności jądra polega na rozpoczęciu pracy od najnowszej stabilnej wersji jądra (dla dużych funkcji) lub rozpoczęciu pracy od najnowszego oznaczonego kandydata do wydania.

W międzyczasie możesz również wykonać kopię zapasową swoich postępów, wypychając gałąź funkcji na serwer, a także możesz przesłać gałąź funkcji na serwer, aby udostępnić ją komuś innemu i uzyskać opinie, zanim funkcja zostanie ukończona, zanim będziesz musiał zamień kod w stałą funkcję bazy kodu, z którą każdy * projekt musi sobie poradzić.

Strona podręcznika gitworkflows jest dobrym wprowadzeniem do przepływów pracy, dla których zaprojektowano Git. Również dlaczego Git jest lepszy niż X omawia przepływy pracy git.

Duże, rozproszone projekty

Dlaczego potrzebujemy poruczników w zespole współpracującym z dobrymi praktykami i dobrymi nawykami projektowymi?

Ponieważ w projektach takich jak Linux jest tak wielu zaangażowanych ludzi, którzy są tak rozproszeni geograficznie, że tak trudno współpracować jak mały zespół, który dzieli salę konferencyjną. (Podejrzewam, że w celu opracowania dużego produktu, takiego jak Microsoft Windows, który nawet jeśli wszyscy znajdują się w tym samym budynku, zespół jest po prostu zbyt duży, aby utrzymać poziom współpracy, który sprawia, że ​​scentralizowany system VCS działa bez poruczników).

Dlaczego nie wykorzystać ich w tandemie? W moim obecnym projekcie jesteśmy zmuszeni używać CVS. Jednak przechowujemy również lokalne repozytoria git w celu opracowania funkcji. Jest to najlepsze z obu światów, ponieważ możesz wypróbować różne rozwiązania i zachować wersje tego, nad czym pracujesz, na własnym komputerze. Pozwala to na wycofanie się do poprzednich wersji funkcji lub wypróbowanie kilku podejść bez popełniania problemów podczas zepsucia kodu. Posiadanie centralnego repozytorium daje zatem korzyści z posiadania scentralizowanego repozytorium.

Nie mam osobistego doświadczenia z DVCS, ale z tego, co zbieram z odpowiedzi tutaj i niektórych powiązanych dokumentów, najbardziej podstawową różnicą między DVCS i CVCS jest stosowany model roboczy

DVCS

Działający model DVCS polega na tym, że wykonujesz izolowany rozwój . Tworzysz swoją nową funkcję / poprawkę w oderwaniu od wszystkich innych zmian, aż do momentu, gdy zdecydujesz się udostępnić ją reszcie zespołu. Do tego czasu możesz dokonywać dowolnych odpraw, ponieważ nikt inny nie będzie się tym przejmował.

CVCS

Model roboczy CVCS (w szczególności Subversion) polega na tym, że pracujesz wspólnie nad rozwojem . Tworzysz swoją nową funkcję / poprawkę błędu w bezpośredniej współpracy ze wszystkimi pozostałymi członkami zespołu, a wszystkie zmiany są natychmiast dostępne dla wszystkich.

Inne różnice

Inne różnice między svni git/ hg, takie jak korekty kontra zestawy zmian, są przypadkowe. Bardzo możliwe jest utworzenie DVCS na podstawie zmian (tak jak ma je Subversion) lub CVCS na podstawie zmian (jak mają Git / Mercurial).

Nie zamierzam polecać żadnego konkretnego narzędzia, ponieważ zależy to głównie od modelu roboczego, z którym ty (i twój zespół) czujesz się najlepiej.
Osobiście nie mam problemów z pracą z CVCS.

• Nie boję się sprawdzania rzeczy, ponieważ nie mam problemów z wprowadzeniem ich w stan niekompletny, ale możliwy do skompilowania.
• Kiedy doświadczyłem piekła scalającego, było to w sytuacjach, w których miałoby to miejsce zarówno w / jak svni git/ hg. Na przykład, V2 niektórych programów było utrzymywane przez inny zespół, wykorzystujący inny VCS, podczas gdy my rozwijaliśmy V3. Czasami poprawki błędów musiałyby być importowane z V2 VCS ​​do V3 VCS, co w zasadzie oznaczało robienie bardzo dużych odpraw w V3 VCS (wszystkie poprawki w jednym zestawie zmian). Wiem, że to nie było idealne, ale decyzja zarządu dotyczyła użycia różnych systemów VCS.