Bug 130235 - I18N - CVS diff encoding error
I18N - CVS diff encoding error
Status: RESOLVED INVALID
Product: utilities
Classification: Unclassified
Component: Diff
6.x
All Windows XP
: P2 (vote)
: TBD
Assigned To: diff-issues@utilities
diff-issues@utilities
: I18N
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-16 03:12 UTC by tetsu
Modified: 2008-09-17 12:25 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
screenshot (51.72 KB, image/png)
2008-03-28 07:42 UTC, tetsu
Details
resolve window showing not ok mbyte (152.63 KB, image/gif)
2008-04-13 17:15 UTC, Ken Frank
Details
in editor, not correct mbyte was inserted (74.97 KB, image/gif)
2008-04-13 17:24 UTC, Ken Frank
Details
for reference, the correct mbyte in editor (77.14 KB, image/gif)
2008-04-13 17:25 UTC, Ken Frank
Details

Note You need to log in before you can comment on or make changes to this bug.
Description tetsu 2008-03-16 03:12:40 UTC
I am using NB6.1Beta on Windows XP (Japanese edition) with JDK 1.6.0_5.

My project is encoding as UTF-8 (project --> properties --> java source --> encoding ) and comments are wrote in 
Japanese.
1. updated the project using CVS, 
2. try to resolve conflicts using Versioning --> CVS --> Resolve conflicts, 
3. the comment in the source files,  both local and remote source file, are changed to unreadable characters in 
*compare editor*.  Yes, only in the compare editor. n the Java source editor, they are displayed normally .

I guess the compare editor doesn't show the source code with the same encoding type as the project setting.
Comment 1 Ken Frank 2008-03-16 18:14:58 UTC
marking as p2 since encoding issue.

problem like this has been seen in the past, but had been fixed for that case.

to issue filer tetsu:

- if you don't do resolve conflicts, but just use diff menu choice while doing other editing,  does the japanese
characters show ok in left and right sides ?

- if you have a separate, new project using win31j encoding, does same situation
of this issue happen ?
(you need to change project encoding in some other project to win31j, then create a new
project; dont change encoding of your existing project and use that one for this experiment)

ken.frank@sun.com
Comment 2 Maros Sandor 2008-03-17 12:13:35 UTC
dab320c96701
Comment 3 Ken Frank 2008-03-17 16:37:58 UTC
Maros,
does the code for subversion, mercurial and clearcase need any changing also 
for this case ? Was it just related to resolve conflicts or to all diff viewing ?
let me know if other issues are needed.

ken.frank@sun.com
Comment 4 Maros Sandor 2008-03-17 16:47:58 UTC
The fix was for all of them.
Comment 5 Ken Frank 2008-03-27 18:48:10 UTC
testsu,

can you see if fix solves the problem you saw ?

the location of build with fix is at
http://bits.netbeans.org/netbeans/trunk/nightly/2008-03-25_13-01-24/

thanks.

ken.frank@sun.com
Comment 6 tetsu 2008-03-28 07:41:42 UTC
Sorry but not yet.

More precisely part of resovled.

I test using nightly building[1]. And found that the non-Enlish characters can be display partly.
It seems that the coding is correct but font is not. 

Whatever, I attached a screenshot. You can understand it at first glance.

[1]http://bits.netbeans.org/netbeans/trunk/nightly/2008-03-25_13-01-24/
Comment 7 tetsu 2008-03-28 07:42:56 UTC
Created attachment 59270 [details]
screenshot
Comment 8 Maros Sandor 2008-03-31 13:41:06 UTC
tetsu: could you answer kfrank's questions?

I cannot reproduce the issue in current trunk.
Comment 9 tetsu 2008-04-01 06:52:08 UTC
About K Frank's question:

- if you don't do resolve conflicts, but just use diff menu choice while doing other editing,  does the japanese
characters show ok in left and right sides ?

Yes, japanese characters show ok. The characters only become unreadable when the "Accept/Accept & Next" button (in 
resolve conlicts windows) is clicked. 

- if you have a separate, new project using win31j encoding, does same situation
of this issue happen ?

Sorry, but I cannot finish this test. Because I am the only guy uses Netbeans in my team. And Eclipse does not support 
win31j encoding. So I cannot make conflicts on my own.
Comment 10 Maros Sandor 2008-04-01 10:33:46 UTC
I tried your "Accept/Accept Next" scenario but it still works for me.
Comment 11 tetsu 2008-04-11 03:26:44 UTC
Sorry, but I tested on nightly build 200804010004 and still have this problem.

One thing may be worth your attention is that my project is shared with Eclipse, which means other colleagues are 
using Eclipse while I'm using Netbeans to edit the same project.


Comment 12 Ken Frank 2008-04-11 05:06:27 UTC
testsu,

thanks for the additional comments.
I am removing incomplete keyword.

as to the eclipse sharing, does the problem happen for you
if its only your own files in netbeans, using the utf-8 encoding 
of project (and I am assuming the characters used in your project 
are all utf-8 enc also ?) ?

if its that others files are in the project files maybe it could be that
those might be in some other encoding ?

but I guess not since all other parts show the characters ok.

ken.frank@sun.om
Comment 13 Ken Frank 2008-04-13 17:11:00 UTC
the problem is seen.

using solaris, in ja euc-jp locale but using default utf-8 project encodings.

1. create java project and put under cvs.
2. create another repos for project using a different local directory.
3. both projects are shown in ide explorer
4. change a line in first project file and commit - use multibyte characters.
5. change a line in second project, same file, same line, different mbyte characters and update
6. get the resolve conflicts message.
7. choose resolve conflicts and that window appears.
8. the mbyte is not correct in both windows - see attached.
(another attached gif shows the source file with correct looking mbyte for reference)
9. resolve anyway and the incorrect mbyte is saved into the java file.
(see another attached gif)

I think it can be good if this is fixed in the first patch for 6.1

ken.frank@sun.com
Comment 14 Ken Frank 2008-04-13 17:15:05 UTC
Created attachment 60100 [details]
resolve window showing not ok mbyte
Comment 15 Ken Frank 2008-04-13 17:24:28 UTC
Created attachment 60101 [details]
in editor, not correct mbyte was inserted
Comment 16 Ken Frank 2008-04-13 17:25:09 UTC
Created attachment 60102 [details]
for reference, the correct mbyte in editor
Comment 17 Ken Frank 2008-04-13 17:26:33 UTC
please review encoding handling of other such resolve
or diff windows for cvs, hg and subversion modules
to see if changes/fixes might be needed for those
in context of this situation.
Comment 18 Ken Frank 2008-04-13 17:39:30 UTC
using java projects with euc-jp project encoding, and same steps as below recent
comments, the mbyte shows ok in resolve conflicts windows and in editor after
accepting the resolve choice.

thus it could be assumption of encoding to be used; perhaps in problem case,
its using encoding of the locale user is in vs the project encoding since they
are different there (euc-jp encoding of locale but utf-8 of project)
but in this case here they are the same (euc-jp of locale and euc-jp of project)

ken.frank@sun.com
Comment 19 Ken Frank 2008-04-21 20:16:06 UTC
any update on if this can be fixed for first 6.1 patch ?

ken.frank@sun.com
Comment 20 Maros Sandor 2008-04-22 12:57:18 UTC
No, we do not plan to do a patch for 6.1.
Comment 21 Maros Sandor 2008-06-18 15:28:43 UTC
I cannot reproduce it in current trunk.
Comment 22 Peter Pis 2008-09-17 12:25:30 UTC
Without requested information for long time - INVALID. We can't do anything in this case, so please reporter add
requested information and reopen issue. Thanks in advance.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo