Сохраните патч в синхронизации с изменяющимся источником
На Linux: если Вы знаете PID, Вы можете кошка cmdline файл для того файла. Например:
cat /proc/PID/cmdline
Это, вероятно, перестанет работать, если двоичный файл был перемещен после того, как программа была запущена.
И конечно:
lsof -n | grep PID | grep ' txt '
и:
ls -la /proc/PID/exe
который является символьной ссылкой на исполняемый файл.
Эта проблема известна как слияние. У Вас есть исходный файл A и две измененных версии B и C, и Вы хотите сделать версию D, которая комбинирует обе модификации. Это только работает, если изменения независимы; иначе слияние является ручным процессом. Обработка слияний параллельных изменений в исходном коде является частой задачей в разработке программного обеспечения.
В простых случаях, патч, произведенный diff будет уже работать, если исходный файл изменился. patch утилита позволяет некоторый “пух”: если Вы сделаете разность от до B, и области, затронутые той разностью, идентичны (но возможно при различных смещениях в файле) в A и C, то патч будет применяться чисто на C. Это работает хорошо пока измененные области в B, и C не в тех же местоположениях (должно быть разделение нескольких строк).
Когда патчи не применяются чисто, слияние является трудной и проблемно-ориентированной проблемой. Например, рассмотрите эти два изменения:
A B C
a=2 a=3 b=2
x=a x=a x=b
Люди склонны определять шаблон, который изменил B 2 кому: 3 и C переименовал a кому: b, таким образом, результат слияния должен быть b=3, x=b. Но автоматизированные инструменты, вероятно, отметят первую строку как конфликт, потому что она была изменена двумя различными способами.
Запись патча, который “делает что-то разумное” и к B и к C, является трудной (полной AI) проблемой. В практических случаях, для многих типичных ситуаций, с помощью diff -u A B поскольку патч имеет тенденцию или работать и производить желаемый D из C или сбой с ошибкой при указывании, что патч не применяется чисто.
Я действительно не рекомендовал бы использовать sed для такой вещи. Проблема, что, даже если патч применяется, это может часто быть с "пухом" - что означает, что некоторые строки контекста не подобраны отлично. В то время как это часто означает, что базовый окружающий код изменился немного, это может также означать, что патч применялся в неправильном месте (я видел, что это происходит, это не было хорошо и не легко отладить).
Кроме того, даже если патч применяется чисто, возможности состоят в том, что он не имеет никакого смысла семантически больше. Для ловли этого однако необходимо знать об изменениях, которые произошли в исправленном коде.
По указанным причинам это считают хорошей практикой для рассмотрения по крайней мере чего-либо, что применяется с пухом (и, вероятно, также поверхностно проверьте то, что применяется со смещением). При наличии больше, чем значение по умолчанию 3 строки контекста могли бы быть хорошей идеей также.
Пройдя большое предупреждение, один из способов сделать это относительно безболезненно использует систему управления версиями, вероятно, усовершенствованный distribudet один как, например. mercurial или git. Мнения о выборе между этими двумя варьируются, Подвижный немного более подобно более старому CVS и SVN, чем Мерзавец и возможно также имеет лучшую кривую обучения (whikle, Мерзавец, как утверждают, более многофункционален).
В Подвижном имеет расширение Подвижных очередей (MQ) точно для этих случаев. Сообщение в блоге этого Steve Losh является довольно хорошим введением в использование MQ, и другое хорошее чтение является этим руководством по MQ на веб-сайте разработчика Mozilla.
Время от времени, patchutils может пригодиться также.
-
1Спасибо за тщательно продуманный ответ и ссылки. Я проверю их. Я понимаю риски, однако, это не об инструменте, а о его использовании, и любой инструмент ценен в некотором контексте. – majkinetor 07.01.2013, 16:47