Jestem maniakiem Subversion, dlaczego powinienem brać pod uwagę Mercurial, Git lub inny DVCS?

300

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.

Robin Maben
źródło
8
Bardzo mnie to interesuje. Subversion pasuje do tego, w jaki sposób nauczono mnie myśleć o kontroli wersji (pochodzącej z CVS i tym podobnych). Niemniej jednak, mimo że musiałem użyć Mercurial i Git, aby wypróbować poprawki błędów dla projektów open source, nie byłem jeszcze przekonwertowany.
Berin Loritsch,
29
+1 za pytanie. W dzisiejszych czasach kult ładunków, który jest dystrybuowany jest po prostu lepszy, szybszy, prostszy, bardziej naturalny i bezproblemowy oraz o 90% bardziej błyszczący w porównaniu do scentralizowanego. Tyle że niekoniecznie tak jest. Są to różne narzędzia i każde z nich może mieć zalety w niektórych kontekstach i wady w innych kontekstach.
Joonas Pulakka
17
@Sharpie: Po stosować zarówno svn, gita hgprzez wiele lat, jestem w pełni świadoma swoich zalet i wad. Chociaż z gitpewnością jest najpotężniejszy z nich, ważne jest, aby pamiętać, że mocniejszy nie oznacza automatycznie lepszego . Emacs jest z pewnością potężniejszy niż jakikolwiek edytor tekstowy javascript działający w przeglądarce internetowej, ale, o dziwo, piszę teraz ten komentarz w edytorze tekstowym przeglądarki javascript! Prostota , a nawet głupota, ma wartość w wielu kontekstach. Korzystanie ze scentralizowanego svni podobnego do git-svnlokalnego oferuje to, co najlepsze z obu światów.
Joonas Pulakka 10.01.11
9
@Sharpie: To dobrze, że ci się podoba. Ale zawodowiec jednego człowieka to oszustwo drugiego człowieka. Niektórzy uważają przejrzystość jednego scentralizowanego repozytorium z jednym kanonicznym pniem za niewiarygodnie cenne. Oto prezentacja, w jaki sposób Google przechowuje kod źródłowy wszystkich swoich projektów, ponad 2000, w jednym pniu kodu zawierającym setki milionów linii kodu, a ponad 5000 programistów uzyskuje dostęp do tego samego repozytorium. Wolisz 5000 serwerów i historię 2000 projektów na biurku każdego? -)
Joonas Pulakka
21
-1 dla odniesienia Katy Perry. ;)
Amadiere

Odpowiedzi:

331

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

alternatywny tekst

Rozpowszechniany w praktyce ogólnej

alternatywny tekst

Rozłożone w pełni

alternatywny tekst

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:

alternatywny tekst

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:

alternatywny tekst

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

alternatywny tekst

Po

alternatywny tekst

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:

dukeofgaming
źródło
18
Świetna odpowiedź, ale tylko jedno pytanie dla tych z nas na tej samej łodzi co OP: czy możesz wyjaśnić, jak nie istnieje piekło? Czy integrator lub współpracownik nie musi wykonywać tych samych czynności, gdy widelec przestał być aktualny?
Nicole
17
Dobra odpowiedź. Na marginesie: chociaż Spolsky może mieć kilka fajnych punktów, pamiętaj, że stara się również sprzedawać produkt, wykorzystując te punkty jako materiał do sprzedaży, co czyni je nieco stronniczymi.
Martin Wickman,
5
Przeczytałem tę stronę poświęconą reedukacji i nie znalazłem jej z wielu powodów. Zmienię moje pytanie z moim osobistym poglądem na ten temat.
15
Warto również zauważyć, że Git może działać jako klient Subversion, co oznacza, że ​​nie trzeba konwertować wszystkich na Git naraz; kilku członków zespołu może po prostu użyć Git, jeśli im się podoba, a ich indywidualny przepływ pracy ulega poprawie (zwłaszcza dlatego, że łączenie jest znacznie łatwiejsze).
greyfade,
6
@Pierre, DVCS dba o scalanie zmian oprogramowania poszczególnych programistów, ale nie o faktyczne kompilowanie oprogramowania lub przechodzenie istniejących testów jednostkowych. Nadal potrzebujesz innego oprogramowania, aby to robić za każdym razem, gdy zmienia się źródło, a najlepszym rozwiązaniem, jakie mamy obecnie, jest używanie silnika CI (i robienie tego poprawnie)
59

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.


źródło
Prawie postanowiłem spróbować z prawdziwym projektem.
Dobry pomysł. Pamiętaj, aby zagłębić się w sposób myślenia „Naprawdę podoba mi się to!” zamiast „Nie chcę tego robić!”. Jest wiele do nauczenia się. Jeśli wybierzesz git, github ma wiele dobrej pomocy online. Jeśli wybierzesz hg, Joel napisał dobry materiał online. Jeśli wybierzesz bzr, Canonical najprawdopodobniej ma wiele dobrych materiałów online. Inni?
3
Hmm, który zakłada, że ​​myślisz, że bittorrent jest lepszy niż FTP ...
Murph,
2
@Murph, ja też, podobnie jak Blizzard (w co, moim zdaniem, możemy się zgodzić, wie, jak radzić sobie z masową synchronizacją online?). wowwiki.com/Blizzard_Downloader
2
@Murph, uruchamiasz serwer torrent na serwerze i klient torrent na kliencie. Nietrudny. Należy od razu kupić, że tylko pliki, które uległy zmianie, muszą zostać zaktualizowane. Czy zastanawiałeś się również, co rsync zamiast ftp może kupić za aktualizacje przyrostowe?
46

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.

Sharpie
źródło
6
Przepisywanie historii: czy to tylko sprawa Git? Czy też jest to łatwe w Mercurial? (Jeśli tak, to naprawdę muszę to zrobić.)
Paul D. Waite,
3
Robiąc to, należy pamiętać o dyscyplinie jądra Linuksa - mianowicie nigdy nie bazować (ani nie zapisywać historii) oddziału, który opublikowałeś publicznie. Jeśli masz oddziały, które są publiczne do krótkotrwałego użytku (do łączenia w gałęzie, które są często wyrzucane, takie jak linux-next, lub dla kogoś, kto przejrzy, a następnie wyrzuci ich lokalne kopie), możesz bazować na tych oddziałach - ale twój inni użytkownicy powinni jasno stwierdzić, że konwencja dotycząca tego oddziału polega na tym, że można go zmienić i nie należy go włączać w długoterminowe oddziały innych ludzi.
Ken Bloom
4
możesz mieć dostęp do Internetu bez pełnego dostępu do sieci wewnętrznej. To często zdarza mi się podczas podróży.
5
Nie wymaganie dostępu do Internetu to bardzo ważna sprawa, ponieważ stąd bierze się prędkość DVCS. Gdy tylko będziesz musiał wysłać pakiety przez sieć, spowalniasz proces o rząd wielkości mniej więcej bez względu na to, jak dobre jest twoje połączenie.
Adam Lassek
6
@Paul, rozumiem, że w Mercurial można to zrobić, ale nie jest to podstawowa funkcjonalność ani filozofia.
Benjol,
18

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?

filozofodad
źródło
2
Właściwie zaproponowałbym ten argument przeciwko DCVS. Moja firma niedawno przestawiła się na Mercurial z CVS. Ludzie usuwają zmiany innych ludzi podczas fuzji znacznie częściej podczas CVS.
Juozas Kontvainis
@JuozasKontvainis: Nie znam zbyt dobrze mercurial, ale w git możesz zabronić wypychania, które obejmują połączenia, które nie mają HEAD jako elementu nadrzędnego, co uniemożliwia użytkownikom wypychanie zmian, które nie zawierają najnowszych zmian z wzorca. Jestem pewien, że jest coś podobnego w rtęci.
naught101
@ naught101: w rzeczywistości moja firma ma włączone to ustawienie. To, co się dzieje, polega na tym, że programista dokonuje zmian lokalnie, a następnie próbuje wypychać. Otrzymuje odpowiedź z serwera, że ​​potrzebuje scalenia, zanim będzie mógł pchać. Otrzymuje aktualizacje z serwera i próbuje dokonać zatwierdzenia scalania. W tym momencie nie wiem dokładnie, w jaki sposób te osoby dokonały zatwierdzenia scalania, ale kilka razy scalanie zatwierdzenia zasadniczo usuwało zmiany, które otrzymały z serwera.
Juozas Kontvainis
1
Wygląda na to, że ludzie wyciągnęli zmiany, a następnie usunęli zmiany, które otrzymali z serwera podczas łączenia (co jest możliwe). Oczywiście zestaw zmian z serwera nadal tam jest, więc możesz zresetować repozytorium do stanu, w jakim znajdował się przed ich zmianami.
philosodad
1
w rzeczywistości wygląda to tak: randyfay.com/content/avoiding-git-disasters-gory-story fajny, niekrytyczny artykuł o tym, co może pójść nie tak z repozytorium git, jeśli nie wiesz, co robisz.
gbjbaanb
9

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.

Martin Wickman
źródło
2
Git został zaprojektowany do rozproszonej pracy na całym świecie i zachęca ludzi do pracy nad własnymi projektami i tworzenia własnych widelców. To było nie specjalnie zaprojektowany do ciągłej integracji w „małych i wysoce współpracy zespołów”, która jest co OP prosi.
Martin Wickman,
4
Zgadnij co, masz mniejsze / łatwiejsze do rozwiązania konflikty. Ale jeśli dwa ppl zmieniają te same części kodu, masz problem z planowaniem w zespole i nie może go rozwiązać żaden VCS. Rozproszone czy nie.
Martin Wickman,
4
OP jest w kolokacji z wykorzystaniem CI. Oznacza to, że często dokonują wielu małych meldowań (kilka razy dziennie). Biorąc to pod uwagę, nie widzę powodu, dla którego korzystanie z dvcs powinno dawać jakąkolwiek szczególną przewagę, i nie widzę powodu, dla którego miałyby wystąpić jakiekolwiek duże połączenia, a tym samym nie istnieć piekło. Nie poleciłbym jednak svn dla rozproszonego zespołu, ale tutaj tak nie jest.
Martin Wickman,
2
@MartinWickman - Mercurial został zaprojektowany z myślą o szybkim i niedrogim wdrażaniu, rozwijaniu i łączeniu. Brzmi idealnie do ciągłej integracji. Osobiście uważam, że zdolność Alice do rozgałęzienia jej zmian i zasugerowania, aby Bob wyciągnął je i scalił swoje zmiany z tą gałęzią w celu sprawdzenia problemów - wszystko bez dotykania centralnego serwera lub przekazywania zmian w dowolnym miejscu - brzmi jak świetny sposób dla małych i wysoce współpracujących zespołów do pracy.
philosodad
2
Moje 0,02 $. Używałem Subversion, Mercurial i Git teraz do różnych projektów. Subversion wydaje się być najlepszym wyborem dla bardzo ściśle zintegrowanej grupy wykonującej ciągłą integrację. Mercurial lepiej nadaje się dla grup, które mogą wykonać tylko jedną kompilację dziennie z większą ilością zmian kodu za każdym razem (co spowodowałoby problemy z łączeniem w SVN). Git wydaje się być dobrą drogą dla ludzi, którzy mają zespoły, które mogą pracować dni / tygodnie bez faktycznego tworzenia kodu.
Brian Knoblauch,
8

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ć.

Pete
źródło
Bardzo prawda, eksperymentowanie z alternatywami powinno odbywać się automatycznie.
git używa pewnej heurystyki, aby ustalić, czy plik został przeniesiony - jest dobry, ale nie doskonały.
gbjbaanb
Zgadzam się z tym, nawet jeśli nie znosisz nowego narzędzia, którego używają te przeklęte dzieciaki, myślę, że ważne jest, aby zmusić się do przynajmniej wypróbowania nowych rzeczy, zwłaszcza jeśli te wytwarzają ogromne fale.
Tjaart
7

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ę!

Xavier Nodet
źródło
Zgadzam się, git Checkout jest bardzo szybki.
+1 za wskazanie tego, przeskakiwanie między gałęziami /
zestawami
3

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).

Ken Bloom
źródło
Nie rozumiem twojego pierwszego punktu. Czy masz jakieś referencje? Jeśli chodzi o ostatni, podzieliłbym projekt na osobne komponenty. Nigdy nie pracowałem nad tak dużym projektem, maksymalna liczba programistów, których dostałem przy tym samym projekcie, to dwa tuziny.
@Pierre. Z pewnością rozsądne jest podzielenie projektu na osobne komponenty. Ponieważ Linux jest monolitycznym jądrem, oznacza to (zasadniczo), że wszystkie sterowniki urządzeń muszą być opracowane w tym samym repozytorium, mimo że każdy z nich jest zasadniczo odrębnym projektem. Jednocześnie chcą, aby ich bardziej doświadczeni architekci sprawnie wprowadzali szeroko zakrojone zmiany, które dotykają wszystkich tych sterowników, więc rozbicie ich na różne repozytoria będzie uciążliwe. Więc git (i porucznicy) dobrze im odpowiadają za zarządzanie tymi różnymi problemami.
Ken Bloom
Być może zainteresuje Cię również to, co Martin Fowler ma do powiedzenia na temat przepływów pracy SVN w porównaniu z Git i Mercurial. martinfowler.com/bliki/VersionControlTools.html
Ken Bloom
2
Regularnie robię bisekcje na SVN, aby znaleźć błędy. Jedyną różnicą w przypadku Git jest to, że nie wszystko jest automatyczne. Ale to nie wystarczyłoby nam do zmiany.
Xavier Nodet
1
Znaczenie git bisect dla małych zespołów jest prawie zerowe. Rozumiem to dla jądra, w którym setki zmian od różnych ludzi są jednocześnie łączone i niszczą rzeczy, ale kiedy masz zespół 5, zwykle możesz wyeliminować wszystkie potencjalne winne z wyjątkiem 2-3, szybko przeglądając log.
blucz
2

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.

Vadim
źródło
Ale możesz po prostu skonfigurować centralne repozytorium za pomocą DVCS (i możesz kontrolować uprawnienia tak samo ściśle, jak za pomocą CVCS. Więc jakie są korzyści?
naught101
To prawda, ale centralne repozytoria git mogą być trudne do skonfigurowania, jeśli jesteś w środowisku Windows. Myślę, że to właściwie jedyna, o której mogłem myśleć. Byliśmy zmuszeni używać CVS na poziomie korporacyjnym, więc tak naprawdę nie mieliśmy wielkiego wyboru.
Vadim,
1

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.
Bart van Ingen Schenau
źródło
Nie sądzę, że izolowany rozwój jest faktycznie działającym modelem DVCS. Jedną ważną cechą DVCS jest to, że inni członkowie zespołu mogą pobierać lokalne zmiany lub klonować lokalne repozytorium. Zgadzasz się, kiedy chcesz, twoje zmiany są zawsze dostępne, a twoje błędy nie mogą spowodować masowego spustoszenia.
philosodad
@philosodad: Jeśli inni pobiorą kod z mojego repozytorium, nie znając jego stanu, nadal może to spowodować spustoszenie. Jedyną różnicą jest to, za czyją to odpowiedzialność. A mój kod nie zawsze jest dostępny. To wciąż zależy od tego, czy moje systemy są skonfigurowane do dostępu zewnętrznego.
Bart van Ingen Schenau,
Jeśli ludzie ściągną kod z twojego repozytorium i połączą go z własnym, mogą wycofać się niezależnie, bez żadnych masowych problemów. Po drugie, na pewno, jeśli podejmiesz decyzję o odmowie dostępu do bazy kodu i okaleczysz jedną z głównych funkcji systemu, możesz wymusić izolację. To bardzo różni się od systemu modelowanego do izolowanego rozwoju. DVCS nie jest. Twoje zrozumienie działającego modelu DVCS jest po prostu błędne.
Philododad
1
@ philosodad: Myślę, że zaczynam rozumieć to coraz lepiej: każdy może dostać twój bałagan, tak jak w CVCS, ale to już nie twoja wina, ponieważ go nie naciskałeś. :-)
Bart van Ingen Schenau
Cóż ... w pewnym sensie. Ale zazwyczaj Alice najpierw klonuje lub rozgałęzia, a następnie łączy zmiany, co ułatwia udawanie, że nigdy nie widziała twojego błędnego kodu!
philosodad