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

22

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?

Matt
źródło
Wygląda na to, że używasz już SVN jako DVCS (w każdym razie w odniesieniu do rozgałęziania). Jestem pewien, że możesz zrobić prawie wszystko, co Mercurial może zrobić z SVN (i odwrotnie); pytanie brzmi: który z nich jest łatwiejszy w użyciu i wygodniejszy dla konkretnego scenariusza programowania? Myślę, że musisz wypróbować Mercurial, aby zobaczyć, czy warto, czy nie
Cameron
Jestem fanem Mercurial i wyraźnie oferuje on zestaw funkcji SVN, ale biorąc pod uwagę, że te dodatkowe funkcje są naprawdę przydatne tylko w niewielkiej większości projektów. Prawdopodobnie nie potrzebujesz go, to nie zmieni twojego życia, ale dostaniesz więcej funkcji i nic nie stracisz, więc czemu nie?
jiggy
Sprawdziłeś Hg Init ? To samouczek Mercurial napisany przez Joela Spolsky'ego. Zaczyna się od rozdziału dla użytkowników Subversion, ale poza tym oczekuje, że nic nie wiesz o DVCS.
Barry Brown

Odpowiedzi:

11

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.

Karl Bielefeldt
źródło
2
+1! Ponadto, jeśli spróbujesz rzetelnie i gruntownie wypróbować mercurial, jestem pewien, że nie chcesz wracać.
Pete
1
„Musisz zadać sobie pytanie, co zrobiłbyś z tyloma gałęziami, ile chcesz, które są udostępniane komukolwiek, i tylko z nimi” ... ”dwie osoby pracujące po przeciwnych stronach interfejsu? Muszą dzielić kod z każdym z nich inne regularnie, ale nie jest jeszcze wystarczająco stabilny, aby dzielić się nim ze wszystkimi. Mogą utworzyć gałąź, aby dzielić się między sobą, a następnie połączyć ją z powrotem do centralnego repozytorium, gdy będzie gotowa ”. Wszystko to mamy teraz z subwersją.
Matt
@Matt, masz szczęście, ponieważ Twoja firma jest raczej wyjątkiem niż regułą. Większość firm ma bardzo surowe zasady dotyczące tworzenia oddziałów na ograniczonych zasobach centralnego serwera, więc ludzie nawet nie myślą o ich tworzeniu z przyczyn tymczasowych.
Karl Bielefeldt
3
Myślę, że w tej odpowiedzi brakuje faktu, że oryginalny plakat już zmusza SVN do pracy w sposób, który jest znacznie bliższy przepływowi pracy DVCS, niż większość użytkowników SVN uznałaby za wykonalne. W gruncie rzeczy mają już nastawienie DVCS, więc nie jest wymagana zasadnicza zmiana myślenia .
Mark Booth
Dobry punkt @ Mark. W tak małym zespole wiele normalnych konwencji dla większych zespołów wychodzi poza okno. Nadal uważam, że warto ze względu na szybkość.
Karl Bielefeldt
1

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

dfjacobs
źródło
Czy chcemy poświęcić czas na zmianę? Nie, szczególnie nie, kiedy przestawiliśmy się na svn w ciągu ostatnich 2 lat. Dziękuję za komentarze.
Matt
1

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.

Mark Booth
źródło
1
SVN nie powoduje konfliktu w przypadku, o którym wspominasz. Wyskakuje tylko wtedy, gdy oboje zmienicie te same linie. Scalanie jest na ogół większym problemem przy zmianie nazw plików / przeniesieniach lub dodawaniu / usuwaniu w svn, ponieważ nie obsługuje dobrze scalania zmian katalogów. Scalanie SVN daje więcej opcji niż te 2, zazwyczaj używam opcji „użyj ich, a następnie kopalni”, ponieważ ogólnie chcesz zachować oba zestawy zmian, a nie usuwać oba!
gbjbaanb
@gbjbaanb - nie znalazłem tego, dlatego kwalifikowałem swoje doświadczenie z SVN at least the version I've used. W moim rozumieniu jest to, że najnowsza wersja svn nie zrozumieć o wspólnych przodków, ale nie mam doświadczenia i podejrzewam, że istnieje wiele serwerów tam uruchomione starsze wersje SVN, które mają te same problemy.
Mark Booth
Nawiasem mówiąc, uwielbiam fakt, że za pomocą hg(i prawie na pewno git, ale nie próbowałem tego) możesz wziąć plik z trzema klasami, podzielić go na trzy pliki z klasą, a następnie scalić zmiany między gałęzią z plik „połączony” i gałąź z oddzielnymi plikami, dzięki czemu zmiany poszczególnych klas zostaną zastosowane do poprawnych plików. Czysta magia. * 8 ')
Mark Booth
1
gbjbaanb jest poprawny; SVN nie miałby konfliktu w opisywanym scenariuszu. Bardzo łatwo to sobie zademonstrować.
Jeremy
@Jeremy @gbjaanb - Czy edytowana sekcja działa dla Ciebie lepiej? Nie będę się z tobą kłócił o to, jak svnscalenia powinny działać, mam własne doświadczenie w tym svnwierszu poleceń i SVNKit pod Eclipse, gdzie po prostu pobieranie aktualizacji może powodować „konflikty”, które należy rozwiązać ręcznie za pomocą wycinania i wklejania (Nie mogę łatwo powiedzieć „Chcę obu tych zmian, w tej kolejności).
Mark Booth
0

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.

Logika SK
źródło