Community
Participate
Working Groups
Eclipse-SDK-3.4M5 Trying to apply the patch in attachment 90823 [details] for bug 196447, I ran into the following problem: * Trying to apply patch from the Clipboard failed (Opened attachment in Firefox, Copy, Apply --> Unmatched hunks). * Saving the attachment to a file, and applying the patch from the file worked. Investigating the problem, I found the following: * Original Source file had a CR-Only Line ending (I have no idea why): http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.tm.core/terminal/org.eclipse.tm.terminal/src/org/eclipse/tm/internal/terminal/control/CommandInputFieldWithHistory.java?revision=1.9&root=DSDP_Project&view=markup CommandInputFieldWithHistory.java v1.9 line 13->14 package org.eclipse.tm.internal.terminal.control;^Mimport * In the patchfile on disk, the ...control;^Mimport was there, so the hunk succeeded when patching * In the patchfile on the Clipboard, the ^M had been replaced by CRLF, so the hunk failed when patching I checked my Preferences, and General : Compare/Patch : Genereal : "Ignore white space" is switched ON. Therefore, expected behavior would be that the patch succeeds - at least with sum fuzz. What's making the problem real bad, is that the *.rej file is totally unusable in this case. Not a single hunk from the patch gets applied, and the .rej file only has the file header but nothing else. There is no chance getting the patch applied properly from the Clipboard.
I can confirm that there is a problem with applying the patch Martin mentioned [1]. However, my result is slightly different: * When applying the patch from a _file_, it goes well * When applying from _clipboard_ there is a problem with CommandInputFieldWithHistory.java file (patching VT100TerminalControl goes smoothly). I can see a single conflicting hunk, which is strange since there are couple of them in the patch. The .rej file generated for CommandInputFieldWithHistory.java does contain only the first hunk (the only displayed in the patch preview). [1] I used the same patch, and v20080224 of org.eclipse.tm.terminal
Created attachment 108071 [details] JUnit v01 Here is a JUnit, which adopts the patch and the class mentioned in comment 0 so they can be used in org.eclipse.compare.tests. I hope you don't mind Martin. I can change it to something more general if you wish.
Created attachment 108072 [details] mylyn/context/zip
What we're dealing with here is not related to the way line terminators are handled. I did some debugging to make you the option Martin mentioned above works as expected. What causes the pain is the next line. Here is a snippet from the patch: <...> [SPACE]package org.eclipse.tm.internal.terminal.control;[CR][LF] [SPACE][CR][LF] when applying from clipboard or [SPACE][CR] for a file import java.util.ArrayList;[CR][LF] <= this line causes trouble @@ -24,8 +25,12 @@[CR][LF] <...> A line which doesn't start with a special patch character (namely: '@', ' ', '+', '-', '\\') is interpreted as a beginning of a next FileDiff[2]. This is why you can see only the first Hunk. The PatchReader tries to parse the rest of the hunks thinking it's a new FileDiff. I'm pretty sure it fails after that. Anyway, it would be hard to decide whether an unexpected character is actually a malformed line of a current Hunk or is it beginning of a next FileDiff. On the other side, a new FileDiff usually starts with "Index: <...>", but I don't know if this is always true. Adding the missing space at the beginning of the line with "import java.util.ArrayList" makes the patch appliable (with the fuzz factor set to 2).
btw, is it "Wind River" or "Wing River"? :)
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
