Jaki jest najlepszy sposób zamknięcia gałęzi Mercurial?

Question

Czy lepiej najpierw zamknąć gałąź, a następnie połączyć ją z domyślną gałęzią (na przykład) lub najpierw scalić ją, a następnie zamknąć?

Na przykład w TortoiseHg w pierwszym przypadku zobaczysz linię od najbliższego węzła do domyślnej gałęzi. W drugim przypadku zobaczysz linię od ostatniego zatwierdzenia do gałęzi domyślnej i dodatkowy wiersz od ostatniego zatwierdzenia do węzła zamykającego.

Mam nadzieję, że jestem jasny. Może to kwestia gustu ...

Answer 1

Nie ma prawdziwej różnicy między tymi dwiema metodami, gdy mówimy o nazwanych gałęziach, przynajmniej w każdej najnowszej wersji Mercurial. Rzeczy były różne przed 1.5 (?), Ale wyłącznie w tym, że hg heads i hg branches zawierają te "zamknięte" gałęzie w swoich wyjściach - nadal mogą, jeśli podasz komendę -c.

Pamiętaj, że po zamknięciu gałęzi (przy użyciu hg commit --close-branch lub w Żółwiu) skutecznie po prostu zatwierdzasz nowy zestaw zmian, w którym zmiana ma ustawioną flagę, mówiąc, że gałąź X jest zamknięta - możesz łatwo zaktualizować gałąź i otwórz go, wykonując kolejne zatwierdzenie.

Jednak, gdy ponownie otworzy oddział, "pasek", który widzisz w Tortoise, nadal będzie istnieć w poprzednio zamkniętym zestawie zmian, więc z tego powodu osobiście wybrałbym politykę ścisłego łączenia. Jest to bardziej pouczające wizualnie, jak sądzę, widzieć, że łączyłeś się z czymś, z czym byłeś zadowolony (i dlatego zamknął oddział przed scaleniem).

Rzeczy różnią się nieznacznie w przypadku oddziałów "anonimowych", ponieważ nie są uwzględniane w danych wyjściowych hg branches po ich scaleniu i dlatego nie wymagają wyraźnego zamknięcia.

Answer 2

To nie jest kwestia gustu i istnieje różnica. W skrócie, zamknij gałąź, a następnie połącz.

Chodzi o to, że nazwy oddziałów Mercurial to zwykłe "metadane" dla każdego zestawu zmian. Wpływa na wyniki niektórych poleceń, takich jak hg branches pomija zamknięte, lub hg push domyślnie uniemożliwia dodanie nowej głowy na gałąź. Ale znowu - filtruje.

Wewnętrznie, Mercurial widzi repozytorium jako wykres zestawów zmian, DAG, aby być specyficznym. Głowice topologiczne tego wykresu są używane do implementacji logiki, na przykład podczas porównywania lokalnych i zdalnych repozytoriów podczas hg pull. Większa liczba głowic topologicznych może (nieznacznie, ale nadal) wpływać na wydajność - How do closed branches affect Mercurial performance?. Jak również pewna ich liczba może spowodować 400 Bad Request z Mercurial działającego na serwerze IIS - https://bitbucket.org/site/master/issue/8263/http-400-bad-request-error-when-pulling.

Po pierwszym scaleniu, a następnie zamknięciu gałąź jest blisko - w porządku, a człowiek domyślnie nie widzi tej gałęzi. Ale merkuria dostaje inną topologiczną głowę. Spójrz poniżej na wizualne wyjaśnienie. Stąd pierwszy blisko.

close then merge    merge then close 
----------------    ---------------- 

@ default, head    @ default, head 
|        | 
o merge    <--> | x close branch, head 
|\        | | 
| x close branch  <--> o | merge 
| |        |\| 
o | dev on default    o | dev on default 
| |        | | 
| o dev on branch    | o dev on branch 
| |        | | 
| o open branch    | o open branch 
|/        |/ 
o default     o default 

może wyglądać here szczegółowe informacje o tym, jak doszliśmy do tego wniosku.

Answer 3

Moja ostatnia firma odkryła, że ​​istnieje całkiem niezły powód, aby preferować bliskie scalanie.Jak przedyskutowali inne odpowiedzi, w fuzjach i zamknięciach kończy się dodatkowa "głowa topologiczna", podczas gdy w bliskim połączeniu nie pozostawiasz dodatkowej głowy z tyłu.

Okazuje się, że jest to these extra heads add up i może w końcu spowodować problemy w operacjach synchronizacji (gdzie Mercurial musi wynegocjować, które głowy są po której stronie, aby odkryć zestawy zmian do pchania lub przeciągania). Wraz ze wzrostem liczby wiszących głowic topologicznych, operacje te stają się coraz większe, aż do momentu ostatecznego they start to fail. Na szczęście całkiem łatwo można clean them up later, ale najlepiej jest najpierw uniknąć problemu.