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
[-- 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 --]
> 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
[-- 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 --]
> 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
> 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
[-- 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 --]
> 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
> 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
> 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