This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Product Version = NetBeans IDE 4.1 RC1 (Build 200504051930) Operating System = Windows XP version 5.1 running on x86 Java; VM; Vendor = 1.5.0_03; Java HotSpot(TM) Client VM 1.5.0_03-b05; Sun Microsystems Inc. Java Home = d:\Java\jdk1.5.0_03\jre Steps: 1. Create patch("CVS | Patch"), save to the file. 2. Then apply it to the file and view changes. 3. Switch to "Built-in engine". It shows wrong results.
Created attachment 21407 [details] diff built-in engine
Maros already fixed in trunk <http://javacvs.netbeans.org/source/browse/javacvs/libsrc/org/netbeans/lib/cvsclient/command/PipedFilesBuilder.java?r1=1.10&r2=1.11> I have reviewed.
Well, but I'm afraid that this is not related to the problem in javacvs library. The built-in CVS client is not used in this issue, only the "built-in diff engine". I could not reproduce this so far, Peter, please attach the file *before* the patch was applied, *after* the patch was applied and the patch file. Thanks.
And also, attach them as *binary* files. This is very important so that the original end of lines will be retained.
I've actually reproduced it. But one must use a file, which has Window's line endings (\r\n). Therefore this can not be reproduced with files created from NetBeans templates. It looks like a bug in patch action where the GUI diff is created. Because the patch is applied correctly (with the correct newlines).
The problem is, that when comparing the two files, one is read directly from the disk, but the other is read through the EditorSupport (the hack introduced because of proper localization). This mismatch is caused by a bug in DefaultDataObject - it does not return EditCookie. The fix is trivial: Index: DefaultDataObject.java =================================================================== RCS file: /cvs/openide/loaders/src/org/openide/loaders/DefaultDataObject.java,v retrieving revision 1.7 diff -u -r1.7 DefaultDataObject.java --- DefaultDataObject.java 7 Feb 2005 13:53:26 -0000 1.7 +++ DefaultDataObject.java 6 Apr 2005 16:26:23 -0000 @@ -166,6 +166,8 @@ } if ( + c.isAssignableFrom(org.openide.cookies.EditCookie.class) + || c.isAssignableFrom(org.openide.cookies.EditorCookie.Observable.class) || c.isAssignableFrom (org.openide.cookies.PrintCookie.class)
Ok, DefaultDataObject does not provide EditCookie, but why it should? I cannot imagine what you do that can get broken by not providing it.
DefaultDataObject normally provides EditCookie, when all cookies are initialized. But initially, when there is a request for EditCookie, it returns null, because there is missing the provided condition.
Checking in loaders/src/org/openide/loaders/DefaultDataObject.java; /cvs/openide/loaders/src/org/openide/loaders/DefaultDataObject.java,v <-- DefaultDataObject.java new revision: 1.8; previous revision: 1.7 done Checking in test/unit/src/org/openide/loaders/DefautDataObjectHasOpenTest.java; /cvs/openide/test/unit/src/org/openide/loaders/DefautDataObjectHasOpenTest.java,v <-- DefautDataObjectHasOpenTest.java new revision: 1.11; previous revision: 1.10
"#57515: Backport of EditCookie for DefaultDataObject" openide/test/unit/src/org/openide/loaders/DefautDataObjectHasOpenTest.java openide/loaders/src/org/openide/loaders/DefaultDataObject.java Checking in openide/test/unit/src/org/openide/loaders/DefautDataObjectHasOpenTest.java; /cvs/openide/test/unit/src/org/openide/loaders/DefautDataObjectHasOpenTest.java,v <-- DefautDataObjectHasOpenTest.java new revision: 1.10.14.1; previous revision: 1.10 done Checking in openide/loaders/src/org/openide/loaders/DefaultDataObject.java; /cvs/openide/loaders/src/org/openide/loaders/DefaultDataObject.java,v <-- DefaultDataObject.java new revision: 1.7.12.1; previous revision: 1.7 done
Peter, please verify in NB4.1, thanks in advance.
I can still reproduce this in NetBeans IDE Dev (Build 200504111930) and in NetBeans IDE Dev (Build 200504111800).
Just small correction of Peter's comment : I can still reproduce this in NetBeans IDE 4.1 (Build 200504111930) and in NetBeans IDE 4.2/Dev (Build 200504111800).
Created attachment 21567 [details] file, patch and file after patch
The patch is applied correctly. All files have Windows newlines. Thus the problem seems to remain in the diffing. Will try to reproduce...
Reproduced. The problem is not much solvable in general, until issue #42638 is solved. This is caused by the fact that one file (.orig) is loaded through Document (which converts all line-endings to '\n') and the other (.java) is loaded directly from the file via a Reader with the proper encoding. This is because we can obtain the encoding for Java files, but not for other file types. So, the ApplyPatch action can be made smart to detect this case. It must assure that the reader is retrieved through the same conversion mechanism for both original and patched file. DiffAction must take care that when comparing Java files with other files, they must both be loaded through a Document.
Fixed in trunk. When two files are compared, either both of them or none use the encoding hack through EditorKit, which assures that we get consistent line endings. Also the patch supplies the file which should determine the encoding logic. /cvs/diff/src/org/netbeans/modules/diff/DiffAction.java,v <-- DiffAction.java new revision: 1.27; previous revision: 1.26 /cvs/diff/src/org/netbeans/modules/diff/EncodedReaderFactory.java,v <-- EncodedReaderFactory.java new revision: 1.5; previous revision: 1.4 /cvs/diff/src/org/netbeans/modules/diff/PatchAction.java,v <-- PatchAction.java new revision: 1.25; previous revision: 1.24
This belongs to diff - moving to diff module.
Created attachment 21614 [details] The textual patch that fixes this issue.
Verified in NetBeans IDE Dev (Build 200504131800).
+ } finally { + try { + if (r1 != null) r1.close(); + if (r2 != null) r2.close(); + } catch (IOException ioex) {} can leave the second reader opened. REVIEWED
Good point, thanks. Fixed the try/catch in trunk: /cvs/diff/src/org/netbeans/modules/diff/DiffAction.java,v <-- DiffAction.java new revision: 1.28; previous revision: 1.27
Thanks for the review, the fix is merged into release41 branch: /cvs/diff/src/org/netbeans/modules/diff/PatchAction.java,v <-- PatchAction.java new revision: 1.23.2.2; previous revision: 1.23.2.1 /cvs/diff/src/org/netbeans/modules/diff/EncodedReaderFactory.java,v <-- EncodedReaderFactory.java new revision: 1.3.6.2; previous revision: 1.3.6.1 /cvs/diff/src/org/netbeans/modules/diff/DiffAction.java,v <-- DiffAction.java new revision: 1.25.2.2; previous revision: 1.25.2.1