В начале 2003 года Andreas Gruenbacher и Martin Quinson заимствовали подход сценариев Эндрю и опубликовали инструмент под названием «patchwork quilt» [web:quilt], или просто «quilt» (смотрите [gruenbacher:2005] для документ с его описанием). Поскольку quilt существенно автоматизировало управление исправлениями, он быстро приобрел много последователей среди открытых разработчиков программного обеспечения.

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

На шаге обновления вызывается quilt для сканирования каталогов, он обновляет патч со всеми изменениями, которые вы сделали. Вы можете создать один патч поверх первого, который будет отслеживать изменения, необходимые для изменения дерева «дерево с применённым первым патчем» к «дереву применяется второй патч».

Вы можете управлять тем, какие патчи применяются к дереву. Если «извлечь» патч, изменения, внесенные этим патчем исчезнут из дерева каталогов. Quilt помнит, какие патчи вы извлекли, хотя, вы можете так же «вставить» убраный патч еще раз, и дерево каталогов, будет восстановлено с содержащим изменения в патче. Самое главное, вы можете запустить команду «обновить» в любой момент, а верхний применяемый патч будет обновляться. Это означает, что вы можете в любое время изменить и какие патчи применяются и какие изменения внесены в эти патчи.

Quilt ничего не знает об инструментах контроля версий, так что работает одинаково над распакованными архивами или рабочей копией subversion.

В середине 2005 года, Крис Мейсон взял особенности quilt и написал расширение, которое он назвал Mercurial Queues, которое добавило похожее на quilt поведение к Mercurial.

Ключевой разницей между quilt и MQ является то, что quilt ничего не знает о системах управления версиями, а MQ интегрирована в mercurial. Каждый патч, который вы вставляете отображается как ревизия Mercurial. Извлекаете патч, и ревизия уходит.

Потому что quilt не зависит от инструментов контроля версий, он по-прежнему чрезвычайно полезен для программ, чтобы следить за ситуацией, когда вы не можете использовать Mercurial и MQ.

Чтобы начать работу над новым патчем, используйте команду qnew. Эта команда имеет один аргумент, имя patch-а для создания.

MQ будет использовать в качестве фактических имена файлов в директории .hg/patches, как вы можете увидеть ниже.

$ hg tip
changeset:   0:bf7787dcd87d
tag:         tip
user:        Bryan O'Sullivan <bos@serpentine.com>
date:        Thu Feb 02 14:10:01 2012 +0000
summary:     first change

$ hg qnew first.patch
$ hg tip
changeset:   1:322557d9d523
tag:         first.patch
tag:         qbase
tag:         qtip
tag:         tip
user:        Bryan O'Sullivan <bos@serpentine.com>
date:        Thu Feb 02 14:10:01 2012 +0000
summary:     [mq]: first.patch

$ ls .hg/patches
first.patch  series  status

Кроме того, сейчас в директории .hg/patches есть два файла, series и status. Файл series содержит список всех исправлений, которые знает MQ для этого репозитория, с одним патчем в каждой строке. Mercurial использует файл status для внутренней бухгалтерии; он отслеживает все патчи, которые MQ применил в этом репозитории.

	Примечание
	Вам может иногда понадобиться изменить файл series вручную, например, чтобы изменить последовательность, в которой применяются некоторые патчи. Тем не менее, вручную редактировать файл status почти всегда плохая идея, так как легко повредить данные MQ о происходящем.

После того как вы создали свой новый патч, вы можете редактировать файлы в рабочем каталоге, как вы это обычно делаете. Все нормальные команды mercurial, такие как hg diff и hg annotate работают так же, как раньше.

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

$ echo 'line 2' >> file1
$ hg diff
diff -r 322557d9d523 file1
--- a/file1	Thu Feb 02 14:10:01 2012 +0000
+++ b/file1	Thu Feb 02 14:10:02 2012 +0000
@@ -1,1 +1,2 @@
 line 1
+line 2
$ hg qrefresh
$ hg diff
$ hg tip --style=compact --patch
1[first.patch,qbase,qtip,tip]   919b9524323d   2012-02-02 14:10 +0000   bos
  [mq]: first.patch

diff -r bf7787dcd87d -r 919b9524323d file1
--- a/file1	Thu Feb 02 14:10:01 2012 +0000
+++ b/file1	Thu Feb 02 14:10:02 2012 +0000
@@ -1,1 +1,2 @@
 line 1
+line 2

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

Вы можете запускать qrefresh так часто, как вам нравится, так что это хороший способ сохранять «контрольные точки» вашей работы. Обновляйте патч в подходящее время, попробуйте экспериментировать, и если эксперимент не получится, hg revert откатит ваши изменения обратно до последнего обновления.

$ echo 'line 3' >> file1
$ hg status
M file1
$ hg qrefresh
$ hg tip --style=compact --patch
1[first.patch,qbase,qtip,tip]   52117437a1b0   2012-02-02 14:10 +0000   bos
  [mq]: first.patch

diff -r bf7787dcd87d -r 52117437a1b0 file1
--- a/file1	Thu Feb 02 14:10:01 2012 +0000
+++ b/file1	Thu Feb 02 14:10:02 2012 +0000
@@ -1,1 +1,3 @@
 line 1
+line 2
+line 3

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

$ hg qnew second.patch
$ hg log --style=compact --limit=2
2[qtip,second.patch,tip]   d535b10fd01c   2012-02-02 14:10 +0000   bos
  [mq]: second.patch

1[first.patch,qbase]   52117437a1b0   2012-02-02 14:10 +0000   bos
  [mq]: first.patch

$ echo 'line 4' >> file1
$ hg qrefresh
$ hg tip --style=compact --patch
2[qtip,second.patch,tip]   e933fc1784a2   2012-02-02 14:10 +0000   bos
  [mq]: second.patch

diff -r 52117437a1b0 -r e933fc1784a2 file1
--- a/file1	Thu Feb 02 14:10:02 2012 +0000
+++ b/file1	Thu Feb 02 14:10:03 2012 +0000
@@ -1,3 +1,4 @@
 line 1
 line 2
 line 3
+line 4

$ hg annotate file1
0: line 1
1: line 2
1: line 3
2: line 4

Обратите внимание, что патч содержит изменения в нашем предыдущем патче в качестве части своей контекста (вы можете увидеть это более четко в выводе hg annotate).

Пока, за исключением qnew и qrefresh, мы осторожно использовали только обычные команды Mercurial. Тем не менее, MQ предоставляет множество команд, которые проще использовать, когда вы думаете о патчах, как показано на рисунке ниже.

$ hg qseries
first.patch
second.patch
$ hg qapplied
first.patch
second.patch

Предыдущее обсуждение предполагает, что должна быть разница между «знанием» и «применением» патчей и она есть. MQ может управлять патчами применёнными без него к репозиторию.

Применять патч соответствующей ревизии в репозитории, и последствия патча и ревизия видны в рабочей директории. Вы можете отменить применение патча использованием команды qpop. MQ до сих пор знает о, или управляет, извлеченными патчами, но патч уже не имеет соответствующего набора изменений в репозитории, и рабочий каталог не содержит изменения сделанные патчем. Рисунок 12.1, «Применение и отмена патчей в стеке патчей MQ» иллюстрирует разницу между применёнными и отслеживаемыми патчами.

Рисунок 12.1. Применение и отмена патчей в стеке патчей MQ

Вы можете повторно применить отменённый или извлечённый патч используя команду qpush. Она создает новую ревизию соответствующую патчу и изменения патча в очередной раз станут присутствовать в рабочей директории. Ниже приведены примеры qpop и qpush в действии.

$ hg qapplied
first.patch
second.patch
$ hg qpop
popping second.patch
now at: first.patch
$ hg qseries
first.patch
second.patch
$ hg qapplied
first.patch
$ cat file1
line 1
line 2
line 3

Обратите внимание, что как только мы извлекли патч или два патча, вывод qseries остается неизменным, в то время как у qapplied изменился.

Хотя по умолчанию qpush и qpop работают над одним патчем за раз, вы можете вставить и извлечь много патчей в один проход. Опция -a команды qpush приводит к вставке всех неприменённых патчей, а опция -a для qpop приводит к извлечению всех применённых патчей. (Для некоторых других способов вставки и извлечения многих патчей, смотрите раздел Раздел 12.8, «Получение максимальной производительности от MQ» ниже).

$ hg qpush -a
applying second.patch
now at: second.patch
$ cat file1
line 1
line 2
line 3
line 4

Некоторые команды MQ проверяют рабочий каталог, прежде чем что-то делать, и не работают, если они находят какие-либо изменения. Они делают это, чтобы вы не потеряли изменения, которые вы уже сделали, но еще не включили в патч. Пример ниже иллюстрирует это, команда qnew не будет создавать новый патч, если есть изменения, вызванных в этом случае hg add для file3.

$ echo 'file 3, line 1' >> file3
$ hg qnew add-file3.patch
$ hg qnew -f add-file3.patch
abort: patch "add-file3.patch" already exists

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

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

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

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

Алиса распаковала архив, изменила свои файлы, а затем решила, что она хочет создать патч. Она переименовывает свой рабочий каталог, распаковывает архив еще раз (это и обусловило необходимость переименования), и использует опции -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) . Лучше всего, чтобы запустить qnew для создания собственного патча, а затем использовать patch -pN, чтобы применить их исправления, а затем запустить hg addremove чтобу узнать какие файлы добавлены или удалены патчем, а затем выполнить hg qrefresh. Эта сложность может стать ненужной, смотрите issue 311 для деталей.

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

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

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

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

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

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

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

Если qpush не удается применить патч, он выведет сообщение об ошибке и завершит работу. Если он оставит .rej файлы, как правило, лучше устранить отклонения блоков перед добавлением других патчей или какой-либо дальнейшей работой.

Если ваш патч применялся чисто, и больше не может, потому что вы изменили исходный код, на котором основан ваши патч, Mercurial Queues может помочь, смотрите в разделе Раздел 12.9, «Обновление патчей когда исходный код измененился» для подробностей.

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

Разработчик ядра Linux, Крис Мейсон (автор Mercurial Queues), пишет инструмент под названием mpatch ((http://oss.oracle.com/~mason/mpatch/), который принимает простой подход к автоматизации применения блоков отклонённых patch. Команда mpatch может помочь с 4-я распространенными причинами отклонения блока:

Если вы используете mpatch, вы должны быть особенно осторожным, и проверять свои результаты, когда закончите. В самом деле, mpatch применяет метод двойной проверки вывода инструмента, автоматически передавая вас программе объединения, когда он сделает свою работу, так что вы можете проверить свою работу и закончить всё оставшееся слияние.

Если вы хотите, избавиться от патча, воспользуйтесь командой hg qdelete, чтобы удалить файл патча и удалить его из серии патчей. Если вы попытаетесь удалить патч, который все еще применяется, hg qdelete откажется.

$ hg init myrepo
$ cd myrepo
$ hg qinit
$ hg qnew bad.patch
$ echo a > a
$ hg add a
$ hg qrefresh
$ hg qdelete bad.patch
abort: cannot delete applied patch bad.patch
$ hg qpop
popping bad.patch
patch queue now empty
$ hg qdelete bad.patch

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

$ hg qnew good.patch
$ echo a > a
$ hg add a
$ hg qrefresh -m 'Good change'
$ hg qfinish tip
$ hg qapplied
$ hg tip --style=compact
0[tip]   ea28b7ac83fb   2012-02-02 14:09 +0000   bos
  Good change

Команда hg qfinish принимает опцию --all или -a, который преобразует все применённые патчи в обычные ревизии.

Кроме того, можно превратить существующую ревизию в патч, с помощью опции -r команды hg qimport.

$ hg qimport -r tip
$ hg qapplied
0.diff

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

MQ позволяет работать с директорией .hg/patches как с репозиторием, когда вы готовите репозиторий для работы с патчами используя qinit, вы можете передать опцию hg -c для создания каталога .hg/patches как репозиторий Mercurial.

	Примечание
	Если вы забыли использовать опцию hg -c, вы можете просто пойти в каталог .hg/patches в любое время и выполнить hg init. Не забудьте добавить запись в .hgignore о файле status, хотя (hg qinit hg -c делает это за вас автоматически); Вы ведь действительно не хотите, отслеживать файл status.

Для удобства, если MQ замечает, что каталог .hg/patches репозиторий, он будет автоматически выполнять hg add каждый патч, который вы создаете или импортируете.

MQ обеспечивает короткую команду qcommit, запускающую hg commit в директории .hg/patches.

Наконец, для удобства управления директорией патчей, можно определить alias mq на системах Unix. Например, в системах linux c помощью оболочки bash, вы можете включить следующий фрагмент в файле ~/.bashrc.

alias mq=`hg -R $(hg root)/.hg/patches'

После этого можно отдавать команды вида mq pull из главного репозитория.

MQ поддерживает для работы с репозиторием полные патчи ограниченного небольшими отношениями.

MQ не умеет автоматически обнаруживать изменения, внесенные в каталог патчей. Если вы выполнили hg pull, вручную отредактировали, или сделали hg update изменений для патчей или файлом series, вам придется выполнить hg qpop -a and then hg qpush -a в базовом хранилище, чтобы увидеть эти изменения там. Если вы забудете это сделать, вы можете спутать MQ планы применения патчей.

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

Начните с загрузки и распаковки архива исходных кодов, и превратите его в репозиторий Mercurial.

$ download netplug-1.2.5.tar.bz2
$ tar jxf netplug-1.2.5.tar.bz2
$ cd netplug-1.2.5
$ hg init
$ hg commit -q --addremove --message netplug-1.2.5
$ cd ..
$ hg clone netplug-1.2.5 netplug
updating to branch default
18 files updated, 0 files merged, 0 files removed, 0 files unresolved

Продолжим создавать стек патчей и делать изменения

$ cd netplug
$ hg qinit
$ hg qnew -m 'fix build problem with gcc 4' build-fix.patch
$ perl -pi -e 's/int addr_len/socklen_t addr_len/' netlink.c
$ hg qrefresh
$ hg tip -p
changeset:   1:b51e7b2c8901
tag:         build-fix.patch
tag:         qbase
tag:         qtip
tag:         tip
user:        Bryan O'Sullivan <bos@serpentine.com>
date:        Thu Feb 02 14:10:00 2012 +0000
summary:     fix build problem with gcc 4

diff -r fddb0fa5f203 -r b51e7b2c8901 netlink.c
--- a/netlink.c	Thu Feb 02 14:09:59 2012 +0000
+++ b/netlink.c	Thu Feb 02 14:10:00 2012 +0000
@@ -275,7 +275,7 @@
         exit(1);
     }
 
-    int addr_len = sizeof(addr);
+    socklen_t addr_len = sizeof(addr);
 
     if (getsockname(fd, (struct sockaddr *) &addr, &addr_len) == -1) {
         do_log(LOG_ERR, "Could not get socket details: %m");

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

$ hg qpop -a
popping build-fix.patch
patch queue now empty
$ cd ..
$ download netplug-1.2.8.tar.bz2
$ hg clone netplug-1.2.5 netplug-1.2.8
updating to branch default
18 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ cd netplug-1.2.8
$ hg locate -0 | xargs -0 rm
$ cd ..
$ tar jxf netplug-1.2.8.tar.bz2
$ cd netplug-1.2.8
$ hg commit --addremove --message netplug-1.2.8

С помощью конвеера, начинающегося с hg locate выше удаляем все файлы в рабочем каталоге, так что команда hg commit с опцией --addremove может сообщить, какие файлы были действительно удалены в новой версии исходников.

Наконец, применяем ваши патчи поверх нового дерева

$ cd ../netplug
$ hg pull ../netplug-1.2.8
pulling from ../netplug-1.2.8
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 12 changes to 12 files
(run 'hg update' to get a working copy)
$ hg qpush -a
(working directory not at a head)
applying build-fix.patch
now at: build-fix.patch

MQ обеспечивает команду qfold, которая позволяет объединить целые патчи. Она «складывает» патчи имена которых вы указали, в порядке указанном вами, наверх применяемого патча, и объединяет их описания в конечное описание. Патчи должны быть неприменёнными, перед тем как вы их сложите.

Порядок, в котором вы складываете патчи важен. Если верхним применяется патч foo, и вы складываете qfold bar и quux в него, вы в конечном итоге с помощью патча, получите тот же эффект, как при применении сначала foo, потом bar, а затем quux.

Слияние частей патча в другой сложнее, чем слияние целых патчей.

Если вы хотите переместить изменения некоторых файлов, вы можете использовать опции -i и -x команды filterdiff для выбора изменений из одного патча, присоедините ее выход к концу патча, в который хотите их влить. Вам, как правило, не требуется вносить изменения в патч измененный объединением. Вместо этого, MQ сообщит что некоторые блоки отвергнуты, когда вы попытаетесь сделать qpush (те блоки которые вы переместили в другой патч), и вы можете просто сделать qrefresh для удаления из патча дубликатов блоков.

Если у вас есть патч, который имеет несколько кусков изменяющих файл, и вы только хотите перенести часть из них, работа становится более грязным делом, но все равно можно частично автоматизировать его. Использование lsdiff -nvv печатает различные метаданные о патче.

$ lsdiff -nvv remove-redundant-null-checks.patch
bash: lsdiff: command not found

Это команда выводит три различных номера:

Вам придется использовать некоторый визуальный осмотр, и чтение патча, чтобы идентифицировать файл и блок с номерами которые вы хотите, но вы можете передать их в filterdiff используя опции --files и --hunks, чтобы выбрать именно тот файл и блок который вы хотите извлечь.

После этого вы можете вставить этот блок в конец патч назначения и продолжать так как описано в разделе Раздел 12.15.2, «Объединение целых патчей».