Вопрос по – В Mercurial, как применить обратное исправление к определенному файлу?

19

Относится кMercurial: объединение одного файла между ветками в одном репо Я пытаюсь выполнить операцию возврата для одного файла, даже если этот файл был одним из множества участников ревизии, для которой выполняется возврат.

HG, будучи инструментом, ориентированным на изменения, он не хочет работать с файлами.

Самым близким, что я мог найти, было использование hg export для создания diff, ручное редактирование diff, а затем hg import для исправления файла в обратном порядке.

..но тогда я попал в эту досадную ситуацию, когдаhttp://hgbook.red-bean.com/read/finding-and-fixing-mistakes.html утверждает, что есть опция --reverse дляhg patch  когда нет.

Поэтому самое близкое, что я могу придумать, это сгенерировать патч, отредактированный вручную, как описано выше, а затем использовать vanilla patch -R для применения обратного патча.

hg backout Команда может показаться полезной, но на самом деле это красная сельдь.

Должен быть лучший способ, нет?

Опция --reverse предназначена дляpatchнеhg patch. balpha♦

Ваш Ответ

3   ответа
3

Используйте команду возврата.

hg revert -r1 file

Это должно вернуть содержимое файла к версии в редакции 1. Затем вы можете отредактировать его и зафиксировать как обычно.

Это верно, что вы можете сбросить файл обратно к более ранней версии, как это. Это даже сработало бы, если бы файл не был изменен с плохой версии. Но если было сделано больше правок, простой возврат не сработает. Вместо этого вам придется обновиться до плохой ревизии, вернуть файл в хорошую версию, сделать коммит и объединить две головы. Я считаю, что это в основном то, что делает для вас поддержка.
22

Вы можете сделать это, используя только-I (включить имена, соответствующие заданным шаблонам) аргумент для возврата одной строкой:

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

Example Script:

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

Sample output:

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)

Resulting File Contents:

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

обратите внимание, что file1 не хватает места в первой строке после возврата среднего набора изменений, а подробный журнал показывает только один файл, измененный в backout:

$ 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
отступая середина ревизии
Нет, это будет хорошо работать для набора изменений, не относящегося к наконечнику, хотя это потребует от вас "hg merge" в конце. Однако вы все равно получите график истории, который точно отображает то, что произошло, и происхождение набора изменений, в отличие от копирования, сделанного Бальфой, который даст линейный список изменений.
Здорово. Если бы вы опубликовали пример с отказом от скрытого изменения, я бы отметил его правильно. djsadinoff
Я думаю, что понимаю это решение, но этот случай кажется более простым, чем мой, поскольку здесь вы отказываетесь (один из файлов в) от изменения подсказки, тогда как Balpha имеет дело с моим более общим случаем отказа от исторического изменения. djsadinoff
6

hg backout --merge -r revision_where_the_change_happened

объединить измененные изменения в рабочую копию.

Теперь скопируйте файл в свою обычную рабочую копию и подтвердите

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

и выбросить клона, которого вы создали выше.

Таким образом, Mercurial не знает, что существует связь междуrevision_where_the_change_happened и это совершить. Если вы хотите, чтобы Mercurial запомнил это, вместо этого выполните

hg revert {all files except the one in question}

после объединения возврата в рабочую копию и перед фиксацией. Для второго способа вам не нужно работать с клоном, потому что вы хотите сохранить фиксацию возврата.

Я предполагаю, что выбор того, какой путь вы используете, зависит от того, насколько большой частью набора изменений было конкретное изменение файла.

Похожие вопросы