Por que é remendo GNU não para este diff?

Question

G'day,

Editar:. Apenas pensei em mencionar que este pouco longo questão agora é fixo, graças à resposta de Adam Goode abaixo se você está apenas roçando ao passar através

Eu tenho dado um patch para adicionar ao Apache 2.2.14 e um diff unificado não é remendar o arquivo em tudo. Estou usando remendo GNU 2.5.4.

Eu tenho que ignorar espaços em branco porque o patch original não foi feito bem, ou seja, muitos dos diffs são aparentemente para guia -> espaços conversões. Estes tipos de Diffs são ainda menos útil porque o ficheiro de modificao tenha sido modificado em algum lugar ao longo da cadeia de fornecimento, por exemplo svn repositório, sistema Jira, interface web, etc., de modo que todas as guias foram convertidos em espaços de qualquer maneira!

O comando que estou usando no Solaris 10 é:

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

e a saída é:

...

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.

...

Observe o

Hunk #2 succeeded at 86.

linha.

O arquivo de patch contém vários diffs unificados mas o diff relevante é:

...

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

...

e a parte relevante da fonte, após a aplicação do emplastro (supostamente), com alguns contexto adicionado, é:

...

#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)

...

Todos os outros patches parecem ter sido, quer aplicada ou ignorado com sucesso.

Todas as ideias por que isso diff particular não está tomando?

Editar: Depois de reduzir o fator de correção fuzz baixo a zero como recomendado por Adam abaixo, o patch tem trabalhado com sucesso

.

Graças a Adam Goode, se eu pudesse dar-lhe uma outra votação para a resposta que eu iria! Aqui está o parágrafo relevante para fuzz nas diffutils GNU manual, se você estiver interessado.

Editar 2: BTW Há essa ressalva altamente relevante na parte inferior desse número fuzz:

remendo geralmente produz os resultados corretos, mesmo quando ele deve fazer muitas suposições. No entanto, os resultados são garantidos somente quando o patch é aplicado a uma cópia exata do arquivo que o patch foi gerado a partir de.

Infelizmente, neste caso, não posso ter certeza de que sua mod_cache.h é o mesmo que o oficial 2.2.14 mod_cache, h! ) -:

Answer 1

Quando você usa --ignore-whitespace e não use --fuzz=0, você está basicamente dizendo patch que ele deve fazer um melhor esforço remendo, em vez de falhar completamente. Porque é melhor esforço, não há realmente nenhuma maneira de garantir que vai funcionar perfeitamente. Por esta razão, git e Fedora conjunto RPM --fuzz=0 por padrão para que esses tipos de problemas falhar em tempo de patch (em vez de em tempo de execução de compilação ou).

Se você quiser preservar seus arquivos como a montante-tarball + correções, você deve refazer o patch e se certificar de que pode aplicar com --fuzz=0.