How to resolve hiccups by patch program?

How to resolve hiccups by patch program?

[SF Markus Elfring]

Hello,

I wish you a happy new year.

I have found the article "http://gnuarch.org/gnuarchwiki/Process_*.rej_files" that references experiences by Miles Bader. I find his statement "Applying a hunk from diff-mode sometimes succeeds where patch failed." interesting in my case. Can Emacs perform an update really better than other usual tools in any special situations?

A couple of tools are mentioned on the page "http://cyberelk.net/tim/patchutils/". It seems that I am looking for an option or feature that might not be available here so far.
Can a package of reject files be converted by an other program into another change set for a second try if anything went unexpectedly wrong? (Does this approach make sense?)
How much may I trust the applicability of patches that were generated by TortoiseSVN 1.4.1.7992 compared to other command line tools?

I ask because the technical details might be relevant for the open issue "Improve const-correctness" (http://bugs.digium.com/view.php?id=8160) with the Asterisk software. Would you like to share any more ideas for a solution to the observed obstacle?
http://article.gmane.org/gmane.comp.version-control.subversion.tortoisesvn.user/5180

Regards,
Markus

Re: How to resolve hiccups by patch program?

[Tim Waugh]

[-- Attachment #1: Type: text/plain, Size: 802 bytes --]

On Wed, 2007-01-03 at 11:47 +0100, SF Markus Elfring wrote:
> I wish you a happy new year.

And to you.

> I ask because the technical details might be relevant for the open issue "Improve const-correctness" (http://bugs.digium.com/view.php?id=8160) with the Asterisk software. Would you like to share any more ideas for a solution to the observed obstacle?
> http://article.gmane.org/gmane.comp.version-control.subversion.tortoisesvn.user/5180

I have yet to see a patch reject that was created by patch(1) without
good reason.  There are sure to be conflicts of some sort in the patch.
If there are any conflicts at all, they need to be resolved by human
intervention -- there is no other way to be sure that the patch may be
applied without producing an incorrect result.

Tim.
*/


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: How to resolve hiccups by patch program?

[SF Markus Elfring]

> I have yet to see a patch reject that was created by patch(1) without good reason.

Do you know a kind of debug version for the patch program that provides verbose explanations?
Are there any chances to get more informations about the reason?


> There are sure to be conflicts of some sort in the patch.

Can you see it from the example reject file "app_db.c.rej" in the referenced issue tracking system?
http://bugs.digium.com/file_download.php?file_id=12652&type=bug
(I'm sorry - I recognise only my intended updates.)


> If there are any conflicts at all, they need to be resolved by human
> intervention -- there is no other way to be sure that the patch may be
> applied without producing an incorrect result.

This intervention depends on the willingness for cooperation of the involved software developers. (It seems that I get on the nerves of the other side because of their expectations with bug reporting and coding guidelines.)

Regards,
Markus

Re: How to resolve hiccups by patch program?

[Tim Waugh]

[-- Attachment #1: Type: text/plain, Size: 957 bytes --]

On Thu, 2007-01-04 at 09:04 +0100, SF Markus Elfring wrote:
> Can you see it from the example reject file "app_db.c.rej" in the referenced issue tracking system?
> http://bugs.digium.com/file_download.php?file_id=12652&type=bug
> (I'm sorry - I recognise only my intended updates.)

Need to see the file it's being applied to.  Commonly a reject will be
because the file the patch was made against is not the same as the file
the patch is applied to.

> This intervention depends on the willingness for cooperation of the involved software developers. (It seems that I get on the nerves of the other side because of their expectations with bug reporting and coding guidelines.)

No -- you just need to create a clean patch in the first place, i.e. one
that applies directly to the same file the developer is using. :-)

It sounds like the tool you're using is generating the patch against a
different revision that you intend.

Tim.
*/


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: How to resolve hiccups by patch program?

[SF Markus Elfring]

> Need to see the file it's being applied to.  Commonly a reject will be
> because the file the patch was made against is not the same as the file
> the patch is applied to.
>   

Advanced matching algorithms (fuzz factor ...) are used by the patch 
program. I wonder why my updates should not fit in this case.


> No -- you just need to create a clean patch in the first place, i.e. one
> that applies directly to the same file the developer is using. :-)
>   

Do you know any other recommended tools to perform special consistency 
checks on my side before I submit patches from the tool that I trusted 
so far?
I do not see from the example reject file which lines were considered as 
unclean and were the reason for the unexpected rejection. Can I convince 
the patch program to accept the "suspicious" lines in a second run?


> It sounds like the tool you're using is generating the patch against a
> different revision that you intend.

I do not expect such a mismatch from the current TortoiseSVN software. 
The generated patch file contains appropriate revision informations. Do 
I overlook anything from my viewpoint?
http://en.wikipedia.org/wiki/Subversion

Regards,
Markus

Re: How to resolve hiccups by patch program?

[SF Markus Elfring]

> No -- you just need to create a clean patch in the first place, i.e. one
> that applies directly to the same file the developer is using. :-)

Would you like to try a comparison with the current development revision to check if my update suggestion (context-diff from "app_db.c.rej") is still valid?
http://svn.digium.com/view/asterisk/trunk/apps/app_db.c?rev=47783&view=markup

It is strange that the appropriate location could not be found by the tool, isn't it?
Have you ever heard if wrong rejections could be possible by this software?
http://en.wikipedia.org/wiki/Type_I_and_type_II_errors#False_positive_rate

Regards,
Markus

Re: How to resolve hiccups by patch program?

[Tim Waugh]

[-- Attachment #1: Type: text/plain, Size: 387 bytes --]

I'm not entirely sure why you're asking me -- you know that patchutils
is altogether separate from diffutils (which provides diff) and from
patch, don't you?  It seems to me that there is either a problem with
patch (unlikely in my opinion), or with the diff generation tool you are
using, or with the way you are using it.

In any case, patchutils is not involved.

Tim.
*/


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: How to resolve hiccups by patch program?

[SF Markus Elfring]

> In any case, patchutils is not involved.
>   
Well, you are right. - But I hope that your tool box can help to extract 
code places that might be problematic.

Application of your tools:
1. I want to look at a specific patch that is a part of a bigger file.
$ filterdiff -i 'app_adsiprog.c' < const4.patch

2. I have tried an example that is provided in your manual.
http://man-wiki.net/index.php/1:filterdiff
$ filterdiff -i '*.c' --lines=-5 < const4.patch

I don't get any output from those commands. Do I make a mistake here?

Regards,
Markus

Re: How to resolve hiccups by patch program?

[SF Markus Elfring]

> In any case, patchutils is not involved.
>   

But let us see how useful your software is for other usual applications.
I did not get the expected result by the filterdiff command. So I have 
tried an alternative way to extract something.
$ splitdiff -a const4.patch

Files for 76 parts were successfully created. I've looked at the first 
one. "const4.patch.part001" contains two lines at the end that should 
belong to the next file, shouldn't they?
It seems that the text "Index: apps/app_alarmreceiver.c" and "===== ..." 
belongs to a kind of extension. Would you like to support that?
http://en.wikipedia.org/wiki/Diff#Extensions

Would you like to add a command option that the part number will not be 
written as a suffix of the file name?
(I would prefer a name like "test.1.part.patch" to make the work with 
file associations easier.)

Regards,
Markus

Re: How to resolve hiccups by patch program?

[SF Markus Elfring]

> I'm not entirely sure why you're asking me -- you know that patchutils
> is altogether separate from diffutils (which provides diff) and from
> patch, don't you?

I know - I am asking you because I thought that something from your published tool box can help.

I've tried to get more ideas.
http://article.gmane.org/gmane.comp.version-control.subversion.tortoisesvn.user/5191

I did not get suggestions from "bug-patch@gnu.org". Maybe, I'll start another request.

Regards,
Markus