Почему патч GNU не работает для этой разницы? - PullRequest
3 голосов
/ 30 октября 2009

G'day,

Редактировать: Просто подумал, я бы упомянул, что этот довольно длинный вопрос теперь решен благодаря ответу Адама Гуда ниже, если вы просто просматриваете, проходя. Мне дали исправление для добавления в Apache 2.2.14, и один унифицированный diff вообще не исправляет файл. Я использую патч GNU 2.5.4.

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

Команда, которую я использую в Solaris 10:

/usr/bin/gpatch --verbose --ignore-whitespace -p1 -d . \
    <mod_cache.diff

и вывод:

...

Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|Index: httpd/modules/cache/mod_cache.h
|===================================================================
|--- httpd/modules/cache/mod_cache.h
|+++ httpd/modules/cache/mod_cache.h
--------------------------
Patching file modules/cache/mod_cache.h using Plan A...
Hunk #1 succeeded at 24.
Hunk #2 succeeded at 86.
Hunk #3 succeeded at 138.
Hunk #4 succeeded at 163.
Hunk #5 succeeded at 184.
Hunk #6 succeeded at 217.
Hunk #7 succeeded at 271.
Hunk #8 succeeded at 380.

...

Обратите внимание на

Hunk #2 succeeded at 86.

линия.

Файл патча содержит несколько унифицированных различий, но соответствующий разность:

...

Index: httpd/modules/cache/mod_cache.h
===================================================================
--- httpd/modules/cache/mod_cache.h
+++ httpd/modules/cache/mod_cache.h
@@ -86,9 +86,13 @@
 #define DEFAULT_CACHE_MAXEXPIRE MSEC_ONE_DAY
 #define DEFAULT_CACHE_EXPIRE    MSEC_ONE_HR
 #define DEFAULT_CACHE_LMFACTOR  (0.1)
+#define DEFAULT_CACHE_MAXAGE    5
+#define DEFAULT_CACHE_LOCKPATH "/mod_cache-lock"
+#define CACHE_LOCKNAME_KEY "mod_cache-lockname"
+#define CACHE_LOCKFILE_KEY "mod_cache-lockfile"

-/* Create a set of PROXY_DECLARE(type), PROXY_DECLARE_NONSTD(type) and
- * PROXY_DECLARE_DATA with appropriate export and import tags for the platform
+/* Create a set of CACHE_DECLARE(type), CACHE_DECLARE_NONSTD(type) and
+ * CACHE_DECLARE_DATA with appropriate export and import tags for the platform
  */
 #if !defined(WIN32)
 #define CACHE_DECLARE(type)            type

...

и соответствующая часть источника после применения патча (предположительно) с некоторым добавленным контекстом:

...

#define MSEC_ONE_DAY    ((apr_time_t)(86400*APR_USEC_PER_SEC)) /* one day, in microseconds */
#define MSEC_ONE_HR     ((apr_time_t)(3600*APR_USEC_PER_SEC))  /* one hour, in microseconds */
#define MSEC_ONE_MIN    ((apr_time_t)(60*APR_USEC_PER_SEC))    /* one minute, in microseconds */
#define MSEC_ONE_SEC    ((apr_time_t)(APR_USEC_PER_SEC))       /* one second, in microseconds */
#define DEFAULT_CACHE_MAXEXPIRE MSEC_ONE_DAY
#define DEFAULT_CACHE_EXPIRE    MSEC_ONE_HR
#define DEFAULT_CACHE_LMFACTOR  (0.1)

/* Create a set of PROXY_DECLARE(type), PROXY_DECLARE_NONSTD(type) and 
 * PROXY_DECLARE_DATA with appropriate export and import tags for the platform
 */
#if !defined(WIN32)
#define CACHE_DECLARE(type)            type
#define CACHE_DECLARE_NONSTD(type)     type
#define CACHE_DECLARE_DATA
#elif defined(CACHE_DECLARE_STATIC)

...

Кажется, что все остальные исправления были либо успешно применены, либо проигнорированы.

Есть идеи, почему этот конкретный дифференциал не берется?

Редактировать: После снижения коэффициента размытости патча до нуля, как рекомендовано Адамом ниже, патч успешно сработал.

Спасибо Адаму Гуду, если бы я мог дать вам еще один голос за ответ, я бы! Вот интересующий параграф для fuzz в руководстве по GNU diffutils, если вам интересно.

Редактировать 2: Кстати, в нижней части этого нечеткого параграфа есть очень важное предупреждение:

Патч

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

К сожалению, в этом случае я не могу быть уверен, что их mod_cache.h совпадает с официальным 2.2.14 mod_cache, h! ) -

1 Ответ

6 голосов
/ 31 октября 2009

Когда вы используете --ignore-whitespace и не используете --fuzz=0, вы в основном говорите патчу, что он должен сделать патч с максимальными усилиями, а не потерпеть неудачу полностью. Поскольку это лучшее усилие, нет никакого способа гарантировать, что оно будет работать идеально. По этой причине git и RPM-пакет Fedora по умолчанию устанавливают --fuzz=0, поэтому эти типы проблем завершаются ошибкой во время исправления (а не во время компиляции или выполнения).

Если вы хотите сохранить ваши файлы в виде патчей upstream-tarball +, вам следует повторить патч и убедиться, что он может применяться с --fuzz=0.

...