爲什麼GNU補丁失敗了這個差異？

編輯：只是想我會提到，這個有點長的問題已經得到解決得益於以下，如果你同時穿過只是一掠亞當古德的答案。

我一直在考慮一個補丁添加到Apache 2.2.14和一個統一差異不打補丁的文件都沒有。我正在使用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) 

...

其他所有的補丁似乎要麼被成功應用或忽略。

任何想法，爲什麼這個特定的差異未服用？

編輯：按照Adam所建議的方法將補丁模糊係數降至零後，該補丁已成功運行。

感謝Adam Goode，如果我可以給你另一個投票的答案，我會！如果您有興趣，請參閱GNU diffutils手冊中的relevant paragraph for fuzz。

編輯2： BTW有那個模糊的段落底部的此高度相關的警告：

補丁通常會產生正確的結果，即使它必須做出許多猜測。但是，只有在將修補程序應用於從其生成修補程序的文件的確切副本時，才能保證結果。

不幸的是，在這種情況下，我不能確定他們的mod_cache.h與官方的2.2.14 mod_cache，h是一樣的！） - ：

來源

2009-10-30 Rob Wells

它看起來像成功了......？ – bdonlan 2009-10-30 20:22:09

@bdonian它沒有成功的伴侶。來自DEFAULT_CACHE_MAXAGE的四個宏不在最終文件中。 – 2009-10-30 20:47:36

...並且評論也沒有改變。 – 2009-10-30 21:56:29

當你使用--ignore-whitespace而不使用--fuzz=0時，你基本上是在告訴補丁，它應該做一個盡力而爲的補丁，而不是完全失敗。因爲這是最好的努力，所以確實沒有辦法確保它完美地工作。出於這個原因，git和Fedora RPM默認設置爲--fuzz=0，以便這些類型的問題在補丁時（而不是編譯或運行時）失敗。

如果你想保留你的文件爲上游tarball +補丁，你應該重做補丁，並確保它可以適用於--fuzz=0。

來源

2009-10-30 23:55:23

@Adam，謝謝你的回答。 +1！不幸的是，我無法控制補丁的生成。更糟糕的是，創建該補丁的人通過在獨立維護的源代碼樹上應用一系列補丁來使用他們認爲是Apache v2.2.14的基準作爲基準！看起來他們自從2.2.9以來一直這樣做。他們似乎並不想確定它們是否與Apache org參考一致。） - ： – 2009-10-31 12:26:54

爲什麼GNU補丁失敗了這個差異？

回答

相關問題