Jesteśmy maniakami Subversion i chcemy poznać zalety Mercurial [zamknięte]

Po przeczytaniu, że jestem maniakiem Subversion, dlaczego powinienem brać pod uwagę Mercurial, Git lub inne DVCS .

Mam powiązane pytanie uzupełniające. Czytam to pytanie, czytam polecane linki i filmy i widzę korzyści, ale nie widzę ogólnej zmiany myślenia, o której mówią ludzie.

Nasz zespół składa się z 8-10 programistów pracujących na jednej dużej bazie kodu składającej się z 60 projektów. Używamy Subversion i mamy główny bagażnik. Gdy programista rozpoczyna nową sprawę Fogbugz, tworzy gałąź svn, wykonuje pracę nad gałęzią, a po zakończeniu łączy z powrotem do pnia. Czasami mogą pozostać na gałęzi przez dłuższy czas i połączyć pień z gałęzią, aby odebrać zmiany.

Kiedy patrzyłem, jak Linus mówi o ludziach tworzących oddział i nigdy więcej tego nie robią, to wcale nie jesteśmy my. Bez problemu tworzymy prawdopodobnie 50-100 oddziałów tygodniowo. Największym wyzwaniem jest połączenie, ale udało nam się też całkiem nieźle. Staram się łączyć przez case & checkin fogbugz zamiast całego katalogu głównego gałęzi.

Nigdy nie pracujemy zdalnie i nigdy nie tworzymy gałęzi z gałęzi. Jeśli jesteś jedyną osobą pracującą w tej sekcji podstawy kodu, scalanie z łączem głównym przebiega bezproblemowo. Jeśli ktoś inny zmodyfikował tę samą sekcję kodu, scalanie może stać się nieuporządkowane i może być konieczne wykonanie operacji. Konflikty są konfliktami, nie rozumiem, w jaki sposób jakikolwiek system mógłby to zrobić przez większość czasu, chyba że byłby wystarczająco inteligentny, aby zrozumieć kod.

Po utworzeniu gałęzi następujące pobranie plików o rozmiarze ponad 60 KB zajmuje trochę czasu, ale byłby to problem z dowolnym systemem kontroli źródła, którego użyjemy.

Czy jest jakaś korzyść z jakiegokolwiek DVCS, którego nie widzimy, który byłby dla nas bardzo pomocny?

Przeformułuj swoje pytanie: „Jeśli planujemy używać DVCS tylko w sposób scentralizowany, jakie to ma zalety?” Kiedy pytasz w ten sposób, nie robi tego. Jedna gałąź na zadanie jest niezwykle powszechna w VCS. Jeśli się nad tym zastanowić, to lokalna robocza kopia kodu źródłowego na komputerze dewelopera, która zmienia się niezależnie od pnia przez jeden dzień, jest gałęzią, nawet jeśli nikt tak go nie nazywa. Jedyną różnicą między tym a przepływem pracy jest to, że nadajesz tym gałęziom również stałą nazwę na serwerze centralnym. Nie o takim rozgałęzieniu mówią Linus i inni.

Zrozumienie DVCS wymaga fundamentalnej zmiany myślenia. Musisz zadać sobie pytanie, co byś zrobił z tyloma gałęziami, ile chcesz, które są dzielone z kimkolwiek chcesz i tylko z nimi. Obejmuje to gałęzie widoczne tylko dla ciebie.

Możliwości są nieskończone. Na przykład, co powiesz na dwie osoby pracujące po przeciwnych stronach interfejsu? Muszą regularnie udostępniać sobie kod, ale nie jest jeszcze wystarczająco stabilny, aby udostępnić go wszystkim. Mogą utworzyć gałąź, aby udostępnić się między sobą, a następnie scalić ją z powrotem do centralnego repozytorium, gdy będzie gotowa.

Zdolność do dokonywania pośrednich lokalnych zobowiązań jest tego warta sama. Tego właśnie musisz doświadczyć.

Szybkość uzyskana dzięki lokalnemu repo również jest tego warta sama. Tak, początkowy klon będzie nieuchronnie powolny w dowolnym VCS dla repozytorium plików 60k, ale kiedy już to zrobisz, sprawdzenie nowej gałęzi jest o rząd wielkości szybsze z DVCS.

W konkretnym przypadku przejście na DVCS nie przynosi żadnych korzyści. Jesteś zadowolony ze swojego istniejącego systemu, robi wszystko, czego potrzebujesz, więc po co przełączać? SVN jest nadal aktywnym projektem Open Source i ma lepszą, bardziej dojrzałą integrację ze wszystkimi głównymi IDE i narzędziami programistycznymi niż hg lub git. Biorąc pod uwagę wielkość zespołu i liczbę projektów, czy naprawdę chcesz poświęcić czas na przejście na nowe narzędzie, gdy istniejące działa dobrze?

Jeśli masz programistów, którzy po prostu nie mogą działać bez DVCS, skieruj ich do bram svn dla hg lub git. Wyjaśnij im, że ich meldunki w repozytorium svn muszą być zgodne z wszelkimi procedurami i procesami stosowanymi przez resztę zespołu. Kolejną zaletą tego podejścia jest to, że prawdziwi fanatycy DVCS, którzy już korzystają z bramek, nie mówiąc, że możesz teraz wyjść z szafy :-).

Wydaje mi się, że już używasz przepływu pracy, który jest bardzo podobny do przepływu pracy, który wiele osób przyjmuje po rozpoczęciu korzystania z DVCS.

Z twojego punktu widzenia DVCS będzie miał następujące znaczące zalety w stosunku do SVN:

• Po sklonowaniu repozytorium (operacji) można wykonać wiele operacji lokalnie.
  • Przeglądanie dziennika repozytorium nie musi dotykać serwera SVN, więc może być niezwykle szybkie.
  • Podobnie przełączanie gałęzi nie wymaga dostępu do serwera ani lokalnych klonów.
• Ponieważ gałęzie są tylko rozbieżnymi ścieżkami w historii, twoje repozytorium nie jest zaśmiecone każdą gałęzią, którą każdy utworzył (naprawdę tak naprawdę mamy tylko gałęzie wydania w SVN, ale brancheskatalog wciąż ma wiele podkatalogów, które nie są już istotne).
  • W git, po ponownym scaleniu gałęzi i usunięciu referencji, możesz nigdy nie wiedzieć, że nawet tam była.
  • W Mercurial masz do wyboru albo nazwać gałąź (w takim przypadku jest ona zakodowana na stałe w każdym zestawie zmian), albo po prostu utworzyć gałąź bez nazwy (topologiczną), która po cichu połączy się z historią, gdy zostanie z mergepowrotem w default( trunk)
• W SVN gałęzie oddziałów są zbyt niejasne, aby były przydatne. W giti hgsą na równi z kursem.
• DVCS rozumie, że tworzenie oprogramowania jest DAG , tzn. Kiedy się scalasz, powstaje zestaw zmian z wieloma rodzicami. SVN (przynajmniej wersja, której użyłem) tak naprawdę tego nie rozumie.

W tym ostatnim punkcie mówisz

Konflikty są konfliktami, nie rozumiem, w jaki sposób jakikolwiek system mógłby to zrobić przez większość czasu, chyba że był wystarczająco inteligentny, aby zrozumieć kod.

Przechodząc od używania hgwyłącznie do używania svnsamego, a potem z gitsvnmojego doświadczenia wynika, że ​​fuzje są znacznie prostsze i bezproblemowe z hgi gitsvnniż z nimi svn. Połączenia z svn(przynajmniej używaną wersją) powodują znacznie więcej konfliktów, które należy rozwiązać ręcznie.

Jednym z powodów, dla których łączenia są trudniejsze w SVN, jest to, że daje tylko dwie opcje dla każdej linii, która się różni,

• tekst z gałęzi, w której się scalasz
• tekst z gałęzi, do której się scalasz

podczas gdy fuzje z DVCS zazwyczaj dają trzecią opcję, którą jest

• tekst wspólnego przodka obu łączonych gałęzi

Nie lekceważ, jak to jest korzystne, zapewnia znacznie lepszy kontekst dla zmian niż zwykły dwukierunkowy diff.

Podsumowując, proponuję spróbować. Korzystając z narzędzi takich jak gitsvni hgsubversion, możesz nawet wypróbować je przy użyciu obecnych repozytoriów SVN .

^{Zauważ, że utworzenie klonu jest przede wszystkim królewską PItA, ale kiedy to zrobisz, uzyskasz większość mocy DVCS dzięki istniejącemu CVCS.}

Jest jedna ważna zmiana, którą zauważyłem po takim przejściu: zmieniam gałęzie znacznie częściej i dokonuję częściej, niż mógłbym sobie pozwolić na Subversion. Na przykład istnieje wiele maleńkich gałęzi funkcjonalnych, zorganizowanych w sekwencji, i mogę spędzić miesiące dodając bity do każdej z nich, łatwo ponownie je wszystkie sekwencyjnie zmieniając ciągle. Zmiana kolejności scalania gałęzi funkcjonalności jest trywialna.

Ale tak naprawdę nie odeszłam od Subversion. Po prostu używam git jako mojego lokalnego klienta SVN.