Pytanie w sprawie rollback, mercurial – Jak mercurial, jak zastosować odwrotną łatkę do konkretnego pliku?

19

Związany zMercurial: Scalanie jednego pliku między gałęziami w jednym repo , Próbuję wykonać operację wycofania na pojedynczym pliku, nawet jeśli ten plik był jednym z wielu uczestników wycofanych wersji.

HG jest narzędziem zorientowanym na zmiany i nie chce działać na plikach.

Najbliższe, jakie mogłem znaleźć, to użycie hg export do utworzenia diff, ręczna edycja diff, a następnie hg import, aby załatać plik w odwrotnej kolejności.

.. ale wtedy uderzyłem w tę irytującą sytuację, gdziehttp://hgbook.red-bean.com/read/finding-and-fixing-mistakes.html twierdzi, że istnieje opcja --reversehg patch kiedy nie ma.

Najbliższą rzeczą, jaką mogę sobie wyobrazić, jest wygenerowanie ręcznie edytowanej łatki jak powyżej, a następnie użycie waniliowej łatki -R do zastosowania odwrotnej poprawki.

Thehg backout Polecenie wydaje się tutaj przydatne, ale w rzeczywistości jest to czerwony śledź.

Nie ma GOT, aby być lepszym sposobem, nie?

Opcja --reverse tołata, niehg patch. balpha

Twoja odpowiedź

3   odpowiedź
3

Użyj polecenia revert.

hg revert -r1 file

Powinno to przywrócić zawartość pliku do wersji w wersji 1. Następnie możesz go dalej edytować i zatwierdzać w normalny sposób.

To prawda, że ​​możesz przywrócić plik do wcześniejszej wersji, takiej jak ta. To działałoby nawet, gdyby plik nie został zmieniony od czasu złej wersji. Ale jeśli dokonano więcej zmian, to proste przywrócenie nie będzie działać. Zamiast tego trzeba zaktualizować do złej wersji, przywrócić plik do dobrej wersji, zatwierdzić i połączyć dwie głowice. Wierzę, że to w zasadzie to, co robi dla ciebie backout. Martin Geisler
6

Oto co bym zrobił: Użyj świeżego klonu wersji końcówki.

hg backout --merge -r revision_where_the_change_happened

połączyć odwrócone zmiany z kopią roboczą.

Teraz skopiuj dany plik do zwykłej kopii roboczej i zatwierdź

hg commit -m "Reversed the changes to file.h made in revision bla"

i wyrzuć klona, ​​który stworzyłeś powyżej.

W ten sposób mercurial nie wie, że istnieje związek międzyrevision_where_the_change_happened i to zatwierdzenie. Jeśli chcesz, aby mercurial to zapamiętał, zamiast tego wykonaj

hg revert {all files except the one in question}

po scaleniu zatwierdzenia wycofania do kopii roboczej i przed zatwierdzeniem. W drugim przypadku nie musisz pracować na klonie, ponieważ chcesz zachować zatwierdzenie wycofania.

Domyślam się, że wybór sposobu użycia zależy od tego, jak duża część zestawu zmian była konkretną zmianą pliku.

22

Możesz to zrobić za pomocą-I (dołącz nazwy pasujące do podanych wzorców) argument dla wycofania za pomocą pojedynczej linii:

hg backout --merge -I thefiletorevert -m 'message' OFFENDINGREVISIONID

Przykładowy skrypt:

hg init testrepo
cd testrepo
echo -e "line1\n\nline3" > file1
echo -e "line1\n\nline3" > file2
hg commit -A -m 'changes to two files'
perl -pi -e 's/line1/line 1/' file1
perl -pi -e 's/line1/line 1/' file2
hg commit -m 'put spaces in line1'
perl -pi -e 's/line3/line 3/' file1
perl -pi -e 's/line3/line 3/' file2
hg commit -m 'put spaces in line3'
hg backout --merge -I file1 -m 'remove spaces from line1' 1

Przykładowe wyjście:

adding file1
adding file2
reverting file1
created new head
changeset 3:6d354f1ad4c5 backs out changeset 1:906bbeaca6a3
merging with changeset 3:6d354f1ad4c5
merging file1
0 files updated, 1 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)

Wynikowa zawartość pliku:

file1:line1
file1:line 3
file2:line 1
file2:line 3

Zauważ, że brakuje pliku 1 jako spacji w wierszu pierwszym po wycofaniu środkowego zestawu zmian, a pełny dziennik pokazuje tylko jeden plik zmieniony na zapleczu:

$ hg log -v -r tip
changeset:   3:6d354f1ad4c5
tag:         tip
parent:      1:906bbeaca6a3
user:        Ry4an Brase <[email protected]>
date:        Mon Sep 14 12:17:23 2009 -0500
files:       file1
description:
remove spaces from line1
wycofanie środkowego zestawu zmian Ry4an Brase
Fajne. Jeśli zamieściłbyś przykład z wycofaniem zakopanej zmiany, oznaczyłbym to jako poprawne. djsadinoff
Myślę, że rozumiem to rozwiązanie, ale ten przypadek wydaje się prostszy niż mój, ponieważ tutaj wycofujesz (jeden z plików) zmianę końcówki, podczas gdy balpha zajmuje się moim bardziej ogólnym przypadkiem wycofania historycznej zmiany. djsadinoff
Nie, to działałoby dobrze dla zestawu zmian bez końcówki, chociaż wymagałoby to „scalenia hg” na końcu. Wciąż jednak pojawiłby się wykres historii, który dokładnie odzwierciedla to, co się stało, i zmienił pochodzenie, inaczej niż w przypadku kopiowania balpha, co dałoby liniowy dziennik zmian. Ry4an Brase

Powiązane pytania