Поиск и исправление ваших ошибок

ревизий возможно «нарушило контекст», который использует patch, чтобы определить, может ли она применить патч (если это звучит для вас как бред, смотрите раздел Раздел 12.4, «Понимание патчей» для обсуждения строк команды patch). Кроме того, механизм слияние Mercurial будет работать с файлами и каталогами, который был переименованы, изменениями прав, и изменения в двоичных файлах, ни с одним из этих вариантов patch не может работать.

9.4. Изменения, которых быть не должно

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

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

Прежде чем обсудить варианты, которые у вас есть, если вы зафиксировали «грязный пакет» изменений (выглядящий так плохо, что вы хотите выкинуть грязный пакет из головой), позвольте мы сначала обсудим некоторые подходы, которые, вероятно, не будут работать.

Mercurial рассматривает историю как накопление — каждое изменение создаётся поверх всех изменений, которые ей предшествовали — в общем вы не можете просто убрать внесённые изменения. Исключением является тот случай, когда вы только что совершили изменения, и не передали или вытянули их в другой репозиторий. Вот тогда можно смело использовать команду hg rollback, как я уже подробно описаны в разделе Раздел 9.1.2, «Откат транзакции».

После того как вы передали плохие изменения в другой репозиторий, вы все равно сможете использовать hg rollback в локальной копии изменения исчезают, но это не будет иметь последствий которых вы хотели. Изменения будут присутствовать в удаленном хранилище, поэтому они снова появится в вашем хранилище в следующий раз вы будете забирать из него изменения.

Если возникает такая ситуация, и вы знаете, в какие репозитории распространили свои плохие изменения, можно попробовать избавиться от изменении в каждом из этих репозиториев. Это, конечно, не является удовлетворительным решением: если вы пропустите один из репозиториев пока вы стираете, изменения находящиеся в «диком» мире, и может распространяться дальше.

Если вы зафиксировали одно или несколько изменений после изменений, которые вы хотели бы удалить, ваши ревизии в будущем будут раздроблены. Mercurial не предоставляет способа «удалить дыру» в истории, оставив нетронутыми ревизии.

9.4.1. Откат слияния

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

Учитывая плохие слияния, которые были зафиксированы, как правило, лучший способ исправить его — просто попытаться исправить ущерб вручную. Полная катастрофа, которая не может быть легко исправлена своими руками должен происходить очень редко, но команда hg backout может помочь в упрощении очистки. Он предлагает — опцию --parent, которая позволяет определить, к какому из родителей возвращаться при откате слияния.

99

Поиск и исправление ваших ошибок

Рисунок 9.5. Плохое слияние

Предположим, мы имеем граф ревизий, как на рисунке Рисунок 9.5, «Плохое слияние». Мы бы хотели повторить это слияние ревизий 2 и 3.

Один из способов сделать это будет выглядеть следующим образом.

1.Вызываем hg backout --rev=4 --parent=2. Это говорит hg backout откатить ревизию 4, которая является плохим слиянием, а также при определяет какая ревизия выбрать родительской 2, одну из родителей слияния. Эффект может быть показан на рисунке Рисунок 9.6, «Откат слияния, в пользу одного из родителей».

100

Поиск и исправление ваших ошибок

Рисунок 9.6. Откат слияния, в пользу одного из родителей

2.Вызываем hg backout --rev=4 --parent=3. Это говорит hg backout откатить ревизию 4, но на этот раз выбираем родителя 3, другого родителя слияния. В результате показано на рисунке Рисунок 9.7, «Поддержка отката слияния в пользу другого родителя», на котором в это время репозиторий содержит три головы.

Рисунок 9.7. Поддержка отката слияния в пользу другого родителя

101

Поиск и исправление ваших ошибок

3.Повторяете плохое слияние путем объединения двух отозванных голов, что снижает количество голов в хранилище до двух, как это видно на рисунке Рисунок 9.8, «Слияние откатов».

Рисунок 9.8. Слияние откатов

4.Слияние с фиксацией, того что было сделано после плохого слияния, как показано на рисунке Рисунок 9.9, «Слияние откатов».

102