Управление изменениями
сMercurial Queues
12.13.Инструменты сторонних разработчиков для работы с патчами
Когда вы поработаете с патчами некоторое время, вы обнаружите недостаток инструментов, которые помогут вам понять и управлять патчами, с которыми вы имеете дело.
Команда diffstat [web:diffstat] генерирует гистограммы изменений, внесенных с каждым файлом в патч. Она обеспечивает хороший способ «получить смысл» патча — какие файлы он затрагивает, и сколько изменений применит к каждому файлу и в целом. (Я считаю, что это хорошая идея использовать опцию -p diffstat для отображения статистики различий как нечто само собой разумеющееся, так как иначе он будет пытаться делать умные вещи с префиксами имен файлов, которые неизбежно запутают по крайней мере меня).
$ diffstat -p1 remove-redundant-null-checks.patch bash: diffstat: command not found
$ filterdiff -i '*/video/*' remove-redundant-null-checks.patch bash: filterdiff: command not found
Пакет patchutils [web:patchutils] имеет неоценимое значение. Он предоставляет набор небольших утилит, которые следуют «Unix философии» каждая делает одну полезную вещь с патчем. Из команд patchutils я использую больше всего filterdiff, которая извлекает из подмножеств файла патча. Например, если патч, который изменяет сотни файлов в десятках каталогов, один вызов filterdiff может генерировать меньший патч, который затрагивает только файлы, имена которых совпадают с неким шаблоном. Смотрите раздел Раздел 13.9.2, «Просмотр истории патча» для других примеров.
12.14. Хорошие методы работы с патчами
Если вы работаете над серией патчей представляя их свободному программному обеспечению или проекту с открытым кодом, или серии, которую вы намерены рассматривать как последовательность регулярных ревизий которую вы закончили, вы можете использовать некоторые простые методы, чтобы сохранить вашу работу организованной.
Давайте вашим патчам описательные имена. Хорошее имя для патча может быть rework-device- alloc.patch, потому что оно будет сразу же давать вам подсказку на цель исправления. Длинные имена не должны быть проблемой, вы не будете вводить имена часто, а будете работать с такими командами, как qapplied и qtop снова и снова. Хорошее имя становится особенно важным, когда у вас есть несколько патчей над которыми вы работаете, или если вы жонглировали целым рядом различных задач, и ваши патчи только получили только часть вашего внимания.
Помните о том, над каким патч вы работаете. Используйте команду qtop и просматривайте текст ваших патчей чаще, например, с использованием hg tip -p — что быть уверенным в том, где вы находитесь. Я несколько раз работал, и запускал qrefresh не для того патча, которого хотел, и часто сложно перенести изменения в правильный патч после внесения их в неверный.
По этой причине, стоит потратить немного времени, чтобы узнать, как использовать некоторые из утилит сторонних разработчиков, которые я описал в разделе Раздел 12.13, «Инструменты сторонних разработчиков для работы с патчами», в частности, diffstat и filterdiff. Первий даст вам представление о том, какие изменения патч делает, а второй позволяет легко перемещать выбраные блоки из одного патча и в другой.
12.15. Поваренная книга MQ
12.15.1. Управление «тривиальными» патчами
Так как накладные расходы на добавление файлов в новый репозиторий Mercurial настолько низки, есть смысл, управлять патчами его путём, даже если вы просто хотите внести некоторые изменения в архив с исходными кодами, который вы скачивали.
Начните с загрузки и распаковки архива исходных кодов, и превратите его в репозиторий Mercurial.
153
Управление изменениями с Mercurial Queues
$ 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: tag:
tag:
tag:
tag:
user:
date:
summary:
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
154