Której głowy do pozycji na przed dokonaniem scalenia?

Question

Czy preferuje się scalanie?

Co mam na myśli to: mam, powiedzmy, stary rev 1000. W międzyczasie zrobiłem 234 commits i jestem na rev 1234. Teraz muszę wrócić do rev 1000, aby zaimplementować poprawkę dla klienta . Zgadzam się z poprawką, przekazuję wersję do klienta i zatwierdzam 1235.

To drobna zmiana: dotyczy tylko jednego pliku.

W tym momencie mam dwie głowy: 1235 (którego rodzic jest 1000) i 1234. Ich wspólną (grand-grand -...- dominująca) jest 1000.

Gdybym wydać hg merge po nim hg status, Otrzymuję gigantyczną listę zmian.

Jeśli jednak zrobię najpierw hg update -C 1234, a następnie hg merge i hg status, to widzę tylko moją unikalną zmianę (chyba że się mylę, co się stało).

Zasadniczo ten sposób:

hg update -C 1234 
hg merge # (merging 1234 and 1235, my two only heads) 
hg status 

daje inny status niż to:

hg update -C 1235 
hg merge # (merging 1234 and 1235, my two only heads) 
hg status 

Więc w zasadzie, pytam status (hg status) po połączeniu dwóch takich samych głów, ale Wydaje się, że wyjście hg status zależy od głowy, na którym obecnie się znajduję.

Czy to normalne zachowanie, a jeśli tak, to czy istnieje jedna głowa, aby "preferować" drugą?

Czy obie operacje prowadzą do tego samego stanu repozytorium/kodu źródłowego na końcu?

Answer 1

Tak, oba mają taki sam stan końcowy. Fuzje są prawie w 100% symetryczne w Mercurial. Jedyną częścią niesymetryczną jest nazwanych gałęzie:

hg update branch-a 
hg merge branch-b 
hg commit 

będzie stwarzać changeset na branch-a. Aktualizacja do branch-b najpierw utworzy je na branch-b. Możesz zmienić gałąź zatwierdzenia scalenia, wydając hg branch przed zatwierdzeniem, więc domyślna nazwa gałęzi jest bardziej podobna do sugestii.

Jednak w twoim przypadku zdecydowanie zaktualizowałbym wersję do wersji 1234, a następnie scaliłbym poprawkę w tej wersji. Chodzi mi o to, że masz główną linię rozwoju - tutaj pracujesz nad nowymi funkcjami do następnej wersji.

Po poprawce do starej wersji aktualizujesz ją ponownie, tworzysz poprawkę i wydajesz poprawkę do swojego klienta. Następnie utworzyłeś (maleńką) gałąź dla poprawki. Pytanie o to, gdzie należy dokonać aktualizacji przed scaleniem, brzmi teraz:

• Czy chcę kontynuować instalację od błędów? Jeśli tak, to pozostań przy poprawce i połącz ją z główną gałęzią.

• Czy chcę kontynuować w głównej gałęzi? Jeśli tak, zaktualizuj ponownie do głównej gałęzi i scal w niej gałąź błędów.

W tym przypadku sensownym jest jedynie powrót do głównej gałęzi - chcesz poprawić swój błąd wraz z nowymi funkcjami i chcesz dodać więcej funkcji.

Pomyśl o nazwie oddziałów wspomniałem powyżej - nie zrobiłbyś

hg update 1.x 
# fix bug 
hg commit 
hg tag 1.3 

wrócić do serii 1.x swojego oprogramowania, naprawić błąd, i dokonać 1,3 wydanie poprawkowe. Po zakończeniu chcesz połączyć się z gałęzią default. Ponieważ nazwa oddziału jest dziedziczona od pierwszego rodzica w seryjnej, to najbardziej gładka zaktualizować domyślne pierwszy:

hg update default 
hg merge 1.x 
hg commit 

To recommended way to zrobić w Mercurial.