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.
in ja locale solaris, using pseudo localized nb create a java project - default project encoding prop is utf-8 - have some multibyte in the java file. choose view revision - the multibyte is not shown ok. change the project encoding to euc-jp, which is the default encoding of ja solaris locale. create a new java class, add mbyte and choose view revision the mbyte does show ok --> see attached gifs for comparison of correct and incorrect mbyte. when I create some branches and switch to them; same problems occur. so far it seems mbyte is seen ok in other parts of cvs, but please check encoding handling code to make sure. Also, would this problem be in subversion also, that is, is it common code that handles the view revision ?
Created attachment 49938 [details] image
Created attachment 49939 [details] image
since its ok using euc-jp project encoding but not utf-8, am thinking that it assumes the encoding of the locale the user is in, rather than the project encoding. ken.frank@sun.com
Fixed encoding of files opened via View Revision action. /shared/data/ccvs/repository/javacvs/cvsmodule/src/org/netbeans/modules/versioning/system/cvss/ui/history/ViewRevisionAction.java,v <-- ViewRevisionAction.java new revision: 1.5; previous revision: 1.4 /shared/data/ccvs/repository/versioncontrol/util/src/org/netbeans/modules/versioning/util/Utils.java,v <-- Utils.java new revision: 1.10; previous revision: 1.9
I think its ok now as per the issue, but let me clarify on the expectations/rules: that is, if open the project, then change the encoding of it, then create a new class is it expected that the view revision of the original file would show ok after a change ? I don't think that part could be expected since original file was in utf-8 encoding, now the project is using euc-jp encoding, so view revision or diff will show the original file with incorrect multibyte. But I don't think the cvs itself has a memory of what the encoding was for any given file version or branch, so it seems that its ok that the original multibte might not show ok since project encoding is now different ? ken.frank@sun.com
CVS has no memory on file encoding so we really do not know when showing previous revisions, we just take the current encoding from Project.
am verifying based on Maros comments I think this can be another case where, if user changes project encoding of same project, it is possible that file contents of previous created files might not look ok or be processed ok, since we assume the current project encoding to do different things in nb. ken.frank@sun.com