Czy można "nadużywać" funkcji zmiany nazwy Mercurial do śledzenia ruchu bloków kodu?

Question

Czasami stwierdzam, że mam plik, który z biegiem czasu wyrósł na więcej klas/funkcji/whatevers niż mi się podoba. Czas na refaktor! Zwykle znajduję w tym przypadku, że mój jeden plik staje się kilka: sam plus kilka innych plików, z których każdy zawiera odrębne segmenty pliku.

Niestety, po prostu tworzenie tych nowych plików "pęka" trochę historii - ciężko powiedzieć, że te funkcje pierwotnie pochodziły z innego pliku. Jest jeszcze gorzej, jeśli podczas refaktoryzacji wprowadzono inne zmiany w kodzie.

Jeden z moich współpracowników wykazały, że mógłby „abuse” funkcjonalność zmiany nazwy robiąc coś takiego:

hg rename --after original_file new_file_1 
hg rename --after original_file new_file_2 
hg rename --after original_file new_file_3 
hg add original_file 

Rezultatem jest to, że każdy z nowych plików wygląda jak zmiany nazwy z resztą pliku usunięty, a oryginalny plik wygląda tak, jakby zgubił usunięte bloki. Jak dotąd wydaje się to idealne. Obawiam się jednak, że te wielokrotne zmiany będą powodowały pewne pomieszanie fuzji w dół.

Czy jest coś nie tak z tym podejściem "wielu nazw"?

Answer 1

Przed wykonaniem tej czynności powinieneś się upewnić, że jesteś know what hg copy really means.

W skrócie, kopiując plik z original_file do new_file_1 dodaje odsyłacz że Mercurial będzie używać w przyszłości połączy wtedy i tylko wtedy że nie może znaleźć new_file_1 w ramach wspólnego przodka. Zwykle dzieje się tak tylko w pierwszym scaleniu po wykonaniu kopii.

Wykres może lepiej to zilustrować:

old --- edit old --- edit in old copied to new --- edit old --- merge 
    \    /       /
    copy old new --/------- edit new ------------/ 

Zaczynamy changeset gdzie masz plik old. Następnie edytujesz old na jednej gałęzi i kopiujesz old do new w innym. W pierwszym scaleniu edycja do old jest kopiowana do new. W drugim scaleniu nie ma specjalnego traktowania dla new odkąd new znajduje się we wspólnym przodku (zestaw zmian copy old new).

Co oznacza dla twojego przypadku, że istnieje duża różnica w przyszłych połączeniach w zależności od tego, kiedy ludzie zobaczą copy old new. Jeśli możesz zmusić wszystkich do korzystania z nich jako punktu początkowego, wtedy wszystko jest w porządku. Ale jeśli ktoś ma gałęzie wyłączone z zestawu zmian old i faktycznie edytował old w tej gałęzi, wtedy będą one miały konflikt scalania, gdy spróbują połączyć się z zestawem zmian copy old new.

Dokładniej, występują konflikty scalania, jeśli edytowały one jakąkolwiek część pliku old, która nie została skopiowana do pliku new.Konflikty scalania informują o tym, że nastąpiła zmiana w old, którą należy skopiować do new. Jednak, gdy naprawdę zrobiłeś, to otrzymasz nieistotne konflikty scalania w dwóch z trzech nowych plików.

Jeśli właśnie skasowany plik old i dodano trzy nowe pliki, wtedy można jeszcze dostać konflikt scalania tutaj: zostaniesz poproszony

remove changed old which local deleted 
use (c)hanged version or leave (d)eleted? 

Czy wolisz, aby zobaczyć, że wiersz lub zobaczyć Uruchomienie narzędzia scalania zależy od Ciebie - ale teraz wiesz, jakie są konsekwencje hg copy (lub hg rename --after, to naprawdę to samo).

Answer 2

Łatwiej jest użycie hg copy za to:

hg copy original_file new_file_1 
hg copy original_file new_file_2 
hg copy original_file new_file_3 

Teraz 3 mają oryginalną historię. Ale tak, tak czy owak, jest to całkowicie w porządku i powszechnie się robi.