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.
[ JDK VERSION : 1.7.0_45 ] STEPS: * Java project with ISO-8859-1 encoding. * Use characters beyond ASCII range, e.g. german Umlaute "äöüß". * Do diff against older repository version. ACTUAL: See attachment. EXPECTED: No error should occur.
Created attachment 147834 [details] Screen shot
Does the file open normally in editor? Please attach also the IDE log.
The hg module seems to ignore the projects encoding settings when opening versioned files from repository.
If I update to the older revision, the file opens normally. In the diff view the beyond-ASCII characters are displayed corrupted on the left column of the diff view.
Created attachment 147835 [details] NetBeans log
can't reproduce, seems to work, see the screenshot. The best would be for you to attach a simple test repository i can play with and test it on.
Created attachment 147914 [details] screenshot
I would like to help, but without a test case i cannot do it. Also #245340 might be a result of this so i am not able to resolve it either. Please reopen with a test case repo attached. Thanks
Created attachment 147983 [details] Mercurial repository Hi, please excuse the delay. It took a little time to prepare the test case. - Update project from the attached repo and open it. - On project node: Mercurial->Search History - Empty "Branch" and "Limit" fields and do "Search". - Choose "Diff" - Open node of revision 25 and click "KompBefehlsPanel.java" --> voila
(In reply to Ondrej Vrabec from comment #8) > Please reopen with a test case repo attached. Thanks Done. Please let me know if you could reproduce the test case. I use NetBeans IDE from user account but installed as root on Ubuntu-64 14.04.
Thanks. It is caused by a rename/copy of a file. If a file is copied and committed, we loose the connection with the current's file name and encoding and the encoding is set incorrectly for the history file. The same applies to #245340, when a java+form file is renamed, we incorrectly get from history only the java file (the form file is not fetched with the correct name) and data support does not recognize it as java+form pair. fixed: core-main #42b7fd6f0e17
Integrated into 'main-silver', will be available in build *201407190718* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-silver/rev/42b7fd6f0e17 User: Ondrej Vrabec <ovrabec@netbeans.org> Log: Issue #245337 - Encoding problem at diff against repository Try to handle renamed java/form files in a smarter way. When a file is renamed, the original (history) file's encoding is determined from the renamed (current file).
(In reply to Quality Engineering from comment #12) > Integrated into 'main-silver', will be available in build *201407190718* on > http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) > > Changeset: http://hg.netbeans.org/main-silver/rev/42b7fd6f0e17 > User: Ondrej Vrabec <ovrabec@netbeans.org> > Log: Issue #245337 - Encoding problem at diff against repository > Try to handle renamed java/form files in a smarter way. > > When a file is renamed, the original (history) file's encoding is determined > from the renamed (current file). Wouldn't you better determine the encoding from the history's nbproject/project.properties, see bug 245340 comment #12 ?
Fix verified with given test repo, ...but please have a look at bug 245340 comment #12.
Reopened to force attention on last comment.
(In reply to ulfzibis from comment #15) > Reopened to force attention on last comment. The only way would be to completely checkout the project metadata with the files somewhere. But mercurial has no idea where the project metadata may lie if the file does not exist in the current revision. So there is no easy way get the encoding.