为什么GNU补丁失败了?

时间:2009-10-30 20:01:08

标签: c patch unified-diff

天儿真好,

编辑:我想提一下,这个有点长的问题现在已经解决,感谢Adam Goode在下面的回答,如果你只是在经过时略读。

我已经获得了一个补丁,可以添加到Apache 2.2.14,并且一个统一的差异根本没有修补文件。我正在使用GNU补丁2.5.4。

我必须忽略空格,因为原始补丁不能很好地制作,即许多差异看起来似乎是标签 - >空间转换。这些差异甚至不太有用,因为补丁文件已经在传送链的某处被修改,例如, svn存储库,Jira系统,Web界面等,所以所有选项卡都已转换为空格了!

我在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)

...

所有其他补丁似乎已成功应用或忽略。

为什么这种特殊差异没有采取任何想法?

修改:根据以下Adam的建议将修补程序模糊因子降低到零后,修补程序已成功运行。

感谢亚当古德,如果我能给你另一个投票,我会答应!如果您有兴趣,请参阅GNU diffutils手册中的relevant paragraph for fuzz

编辑2: BTW在这个模糊段落的底部有一个非常相关的警告:

  

补丁通常会产生正确的结果,即使它必须做出许多猜测。但是,仅当将修补程序应用于生成修补程序的文件的精确副本时,才能保证结果。

不幸的是,在这种情况下,我无法确定他们的mod_cache.h是否与官方的2.2.14 mod_cache相同,h! ) - :

1 个答案:

答案 0 :(得分:6)

当您使用--ignore-whitespace并且不使用--fuzz=0时,您基本上会告诉补丁它应该做一个尽力而为的补丁,而不是完全失败。因为这是最好的努力,所以实际上没有办法确保它能够完美地工作。出于这个原因,git和Fedora RPM默认设置为--fuzz=0,这样这些类型的问题在补丁时(而不是编译或运行时)失败。

如果要将文件保存为upstream-tarball +补丁,则应重新修补补丁并确保其适用于--fuzz=0