Управление изменениями с Mercurial Queues

abort: patch "add-file3.patch" already exists

Команды, которые проверяют рабочий каталог, все принимают опцию «Я знаю, что я делаю», которая всегда имеет имя -f. Точное значение -f зависит от команды. Например, в hg qnew -f будет включать любые не сохранённые изменения в новый патч который она создает, но hg qpop -f отменит изменения во всех файлах, измененные в результате применения патчей, которые она извлекает. Не забудьте прочитать документацию по опции -f для нужной вам команды, прежде чем использовать её!

12.5.7. Работа с различными патчами сразу

Команда qrefresh всегда обновляет верхний применяемый патч. Это означает, что вы можете приостановить работу по одному патчу (обновив его), извлечь или поместить другой патч наверх, и работать с тем патчем некоторое время.

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

— слой поверх первого — изменения пользовательского интерфейса, использующее код, который вы только что добавили к ядру. Если вы заметили ошибку в ядре в то время как вы работаете на исправлением UI, вы можете легко исправить ядро. Просто вызовите qrefresh для патча пользовательского интерфейса, чтобы сохранить незавершенные изменения и qpop вплоть до патча ядра. Исправьте ошибку ядра, запустите qrefresh для патча ядра и qpush поднявшись к патчу пользовательского интерфейса и работайте с того места, где вы остановились.

12.6. Более подробно о патчах

MQ использует команду GNU patch для применения патчей, так что полезно узнать некоторые более детальные аспекты, как работает patch, и о самих патчах.

12.6.1. The strip count

Если вы посмотрите на заголовок файла патча, вы заметите, что путь к файлу, как правило содержит дополнительные компоненты в начале, которых нет в настоящем пути. Это остаток пути который люди использовали для создания патчей (люди до сих пор это делают, но уже реже с появлением современных средств контроля версий).

Алиса распаковала архив, изменила свои файлы, а затем решила, что она хочет создать патч. Она переименовывает свой рабочий каталог, распаковывает архив еще раз (это и обусловило необходимость переименования), и использует опции -r и -N команды diff для рекурсивно создания патча между не измененным каталогом и измененным. Результатом будет то, что имя не измененного каталога будет в начале пути каждого файла в заголовке иметь имя левого каталога, а путь каталога измененного будет в начале пути иметь правый каталог.

Кто-то получает патч от Алисы, вряд ли будет иметь неизмененный и измененый каталоги с точно такими же именами, команда patch имеет опцию -p указывающую на количество ведущих компонентов пути удаляют при применении патча. Это число называется счётчик удаления.

Опция «-p1» означает «использовать счётчик удаления с первого элемента». Если patch видит имя файл foo/ bar/baz в заголовке файла, он удаляет foo и попытаться применить патч к файлу с именем bar/baz. (Строго говоря, счётчик удаления относится к количеству разделителей пути (и компонентов, которые следуют за ними). Счётчик удаления в значении 1 преобразует foo/bar в bar, но /foo/bar (обратите внимание на дополнительный ведущий слэш ) в foo/bar.)

«Стандартный» счётчик удаления для патчей равен 1, почти все патчи содержат один ведущий компонент пути, который необходимо отрезать. Команда Mercurial hg diff генерирует путь в этой форме, и команда hg import и MQ ожидают патчей со счётчиком удаления равным 1.

Если вы получили патч от кого-то, и вы хотите добавить патч в свою очередь, и патч требует другого счётчика удаления, чем 1, вы не можете просто применить qimport к патчу, потому что qimport еще не имеет опции -p

(смотрите заявку issue 311 [http://www.selenic.com/mercurial/bts/issue311]) . Лучше всего, чтобы запустить qnew для создания собственного патча, а затем использовать patch -pN, чтобы применить их исправления, а затем запустить hg addremove чтобу узнать какие файлы добавлены или удалены патчем, а затем выполнить hg qrefresh. Эта сложность может стать ненужной, смотрите issue 311 [http://www.selenic.com/mercurial/bts/issue311] для деталей.

146

Управление изменениями

сMercurial Queues

12.6.2.Стратегия для применения патчей

Когда patch применяет блок, он пытается использовать последовательно несколько менее точные стратегии, чтобы попытаться применить блок. Этот метод уменьшения точности часто дает возможность применить патч, который был создан на старой версии файла, и применить его на новой версии этого файла.

Во-первых, patch ищет точное совпадение, где номера строки, контекст, и текст, который будет изменен совпадает точно. Если он не может сделать точное соответствие, то он пытается найти точное соответствие для контекста, без информации о номерах строк. Если это удаётся, он сообщает что блок был применен, но имеет смещение от первоначального номера строки.

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

Если ни один из этих методов сработал, patch печатает сообщение о том, что блок отклонен. Он сохраняет отклоненные блоки (называя просто «rejects») в файле с тем же именем и расширением .rej. Он также сохраняет не измененную копию файла с расширением .orig; копия файла без расширения будет содержать изменения, из применённых блоков, которые применились чисто. Если у вас есть патч, который изменяет foo с 6 блоками, а один из них не применяются, вы получите: неизмененный foo.orig, foo.rej содержащие один блок, и foo, содержащий изменения, внесенные в пяти успешных блоках

12.6.3. Некоторые причуды из представления патчей

Есть несколько полезных фактов о том, как patch работает с файлами.

•Это уже должно быть очевидно, но patch не может справиться с бинарными файлами.

•Он также не заботится о бите исполняемости, создает новые файлы читаемыми, но не исполняемыми.

•patch считает удалённый файл, как различие между фалом который удалён и пустым файлом. Так что ваша идея «Я удалил этот файл» в патче выглядят как «каждая строка этого файла была удалена».

•Это относится и к добавленным файлам как к различию между пустым файлом и файлом который будет добавлен. Таким образом, в патче, ваша идея «я добавил этот файл» выглядит как «каждая строка этого файла был добавлена».

•Это относится и к переименованным файлам, как удаление старого файла, и добавление нового. Это означает, что переименованные файлы будут иметь большой след в блоке. (Заметим также, что mercurial в настоящее время не попытаться сделать вывод, когда файлы были переименованы или скопированы и исправлены.)

•patch не может представлять пустые файлы, так что вы не можете использовать патч для представления понятия «Я добавила пустой файл в дерево».

12.6.4. Остерегайтесь неточностей

Применение блоков со смещением, или фактором неточности, часто будет полностью успешным, такие неточные методы естественно оставляют открытой возможность повреждать исправленный файл. Большинство случаев обычно связаны с применением патча два раза, или на неверное место расположения файла. Если patch или qpush постоянно упоминает о смещении или факторе неточности, вы должны убедиться, что измененные файлы правильны.

Часто хорошая идея, обновлять патч, который применился со смещением или фактором неточности, обновление патча порождает новые контекстные связи, которые помогут применить патч чисто. Я говорю: «часто», а не «всегда», потому что иногда обновление патча сделает его не применяемым для различных ревизий основных файлов. В некоторых случаях, например, когда вы поддерживаете патч, который должен находится на вершине нескольких версий исходного дерева, это приемлемо иметь патч применяемый с некоторыми неточностями, если вы убедились в правильности результатов применения патча в таких случаях.

147