이 차이에 대해 GNU 패치가 실패하는 이유는 무엇입니까?

Question

g'day,

편집 : 방금이 다소 긴 질문은 이제 아담 굿의 대답 덕분에 지나가는 동안 아래를 훑어 보면서 고정되어 있다고 언급 할 것입니다.

Apache 2.2.14에 추가 할 패치가 주어졌으며 하나의 통합 Diff가 파일을 전혀 패치하지 않습니다. GNU 패치 2.5.4를 사용하고 있습니다.

원래 패치가 잘 만들어지지 않았기 때문에 공백을 무시해야합니다. 즉, 많은 차이가 탭 -> 공백 변환을위한 것 같습니다. 패치 파일이 전달 체인, 예를 들어 SVN 저장소, JIRA 시스템, 웹 인터페이스 등 어딘가에 수정 되었기 때문에 이러한 종류의 Diff는 훨씬 덜 유용합니다. 어쨌든 모든 탭이 공간으로 변환되었습니다!

내가 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이 권장하는대로 패치 퍼즈 계수를 0으로 낮추면 패치가 성공적으로 작동했습니다.

Adam Goode에게 감사합니다. 만약 내가 당신에게 답변에 대한 또 다른 투표를 할 수 있다면! 여기에 있습니다 퍼즈에 대한 관련 단락 관심이 있다면 GNU Diffutils 매뉴얼에서.

편집 2 : btw 해당 퍼즈 단락의 맨 아래 에이 매우 관련된 경고가 있습니다.

패치는 일반적으로 많은 추측을해야하더라도 올바른 결과를 생성합니다. 그러나 결과는 패치가 패치가 생성 된 파일의 정확한 사본에 적용될 때만 보장됩니다.

불행히도,이 경우, 나는 그들의 mod_cache.h가 공식 2.2.14 mod_cache, h와 동일하다는 것을 확신 할 수 없습니다! )-:

Answer 1

당신이 사용할 때 --ignore-whitespace 그리고 사용하지 마십시오 --fuzz=0, 당신은 기본적으로 패치에 완전히 실패하는 대신 최고의 효과 패치를 수행해야한다고 말하고 있습니다. 최선의 노력이기 때문에 실제로 완벽하게 작동 할 수있는 방법이 없습니다. 이러한 이유로 Git 및 Fedora RPM이 세트를 설정합니다 --fuzz=0 기본적으로 이러한 유형의 문제가 패치 시간에 실패합니다 (컴파일 또는 런타임 대신).

파일을 업스트림-타르 볼 + 패치로 보존하려면 패치를 다시 만들고 신청할 수 있는지 확인해야합니다. --fuzz=0.