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.
on solaris, not sure about linux here ja locale, using pseudo localized nb. import into repository of a project that has non ascii like asian multibyte in project name or path - which is legal after choose repos folder, get error popup svn command returned with following eerror safe data /var/tmp/svn_dummy/<projectname>/ was followed by non ascii byte 228 - unable to convert to/from utf-8/ and cannot proceed with the wizard. it does not matter if encoding project propof the project is utf-8 or euc-jp for example (euc-jp is default encoding of ja solarisi locale. if english only in proj name or path - its all ok. this had not been seen in windows before but has been seen in solaris - there was some mail discussion with Tomas about this in last few weeks.
exception message: org.tigris.subversion.svnclientadapter.commandline.CmdLineException: svn:Safe data '/var/tmp/svn_dummy/' was followed by non-ASCII byte 228: unabl to convert to/from UTF-8 at org.tigris.subversion.svnclientadapter.commandline.CommandLineexecString(CommandLine.java:195) at org.tigris.subversion.svnclientadapter.commandline.SvnCommandLne.importFiles(SvnCommandLine.java:390) at org.tigris.subversion.svnclientadapter.commandline.CmdLineClietAdapter.doImport(CmdLineClientAdapter.java:940) Caused: org.tigris.subversion.svnclientadapter.SVNClientException at org.tigris.subversion.svnclientadapter.SVNClientException.wrapxception(SVNClientException.java:87) at org.tigris.subversion.svnclientadapter.commandline.CmdLineClietAdapter.doImport(CmdLineClientAdapter.java:942) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessrImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethdAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.netbeans.modules.subversion.client.SvnClientInvocationHander.handle(SvnClientInvocationHandler.java:193) at org.netbeans.modules.subversion.client.SvnCmdLineClientInvocatonHandler.invokeMethod(SvnCmdLineClientInvocationHandler.java:60) at org.netbeans.modules.subversion.client.SvnClientInvocationHander.invoke(SvnClientInvocationHandler.java:125) at $Proxy17.doImport(Unknown Source) [catch] at org.netbeans.modules.subversion.ui.wizards.importstep.ImportStp$ImportProgressSupport.perform(ImportStep.java:224) at org.netbeans.modules.subversion.client.SvnProgressSupport.perfrmIntern(SvnProgressSupport.java:80) at org.netbeans.modules.subversion.client.SvnProgressSupport.run(vnProgressSupport.java:73) at org.openide.util.RequestProcessor$Task.run(RequestProcessor.jaa:561) at org.openide.util.RequestProcessor$Processor.run(RequestProcessr.java:986)
could you please attach your messages.log from a NB session you got this problem thanks
Created attachment 49997 [details] log file
log file is attached.
sorry, but i don't see the reported exception in the log file :(
Created attachment 50003 [details] gestures file
sorry - what is saw was in uigestures and in console; part of the msg in uigestures, the rest was from console, as reported in the issue below. ken.frank@sun.com
removing incomplete keyword.
taken from the reporters mail: I recently found a svn for solaris and have perhaps related problem to the 96998 but symptoms are different as to exception and msg in ui from svn. but it happens on command line also, so don't think its a nb problem - but wonder if a nb fix can help ? (and if issue should be filed) if file in svn has mbyte in its name or path or just in the file, then when create or update - get error/exception below. - setting APR_ICONV_PATH does not help - and the error in nb or command line is svn: Safe data '/var/tmp/svn_dummy/' was followed by non-ASCII byte 197: unable to convert to /from UTF-8 - with nb exception at org.tigris.subversion.svnclientadapter.commandline.CommandLine.execStr ing(CommandLine.java:195) at org.tigris.subversion.svnclientadapter.commandline.SvnCommandLine.impo rtFiles(SvnCommandLine.java:390) at org.tigris.subversion.svnclientadapter.commandline.CmdLineClientAdapte r.doImport(CmdLineClientAdapter.java:940) Caused: org.tigris.subversion.svnclientadapter.SVNClientException at org.tigris.subversion.svnclientadapter.SVNClientException.wrapExceptio n(SVNClientException.java:87) at org.tigris.subversion.svnclientadapter.commandline.CmdLineClientAdapte r.doImport(CmdLineClientAdapter.java:942) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j ava:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccess orImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.netbeans.modules.subversion.client.SvnClientInvocationHandler.hand le(SvnClientInvocationHandler.java:193) at org.netbeans.modules.subversion.client.SvnCmdLineClientInvocationHandl er.invokeMethod(SvnCmdLineClientInvocationHandler.java:60) at org.netbeans.modules.subversion.client.SvnClientInvocationHandler.invo ke(SvnClientInvocationHandler.java:125) at $Proxy17.doImport(Unknown Source) [catch] at org.netbeans.modules.subversion.ui.wizards.importstep.ImportStep$Impor tProgressSupport.perform(ImportStep.java:224) at org.netbeans.modules.subversion.client.SvnProgressSupport.performInter n(SvnProgressSupport.java:80) at org.netbeans.modules.subversion.client.SvnProgressSupport.run(SvnProgr essSupport.java:73) at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:539) at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java: 964) Thanks - Ken
> but it happens on command line also, so don't think its a nb problem - but wonder if a nb fix can help ? the netbeans svn module passes the svn commands to the commandline client and if it doesn't work either then i see no way how to fix it on our side.
I wonder if there was typo in my mail about command line since I don't recall it was tried yet. sorry for any misunderstandings here. please let me know command line commands to try this that will might show this error or please try it using scenario first, before closing this for sure. I will reopen just for now until it can be tried, to be sure. And if it is a svn itself problem, can we get release note or olh info about it,or warning in ui, so users will not be confused about if problem is with nb vs svn ? ken.frank@sun.com
e.g. svn import [your_projects_full_path] file:///data/subversion/[your_projects_name]
how was the project created? with 6.0 or maybe with 5.5?
6.0 project; my solaris machine with the svn installed is down now; will try the cmd line when it comes back. ken.frank@sun.com
just for the record: this workls for me on linux System Locale; Encoding = ja_JP (nb); EUC-JP-LINUX
full test would be to - have mbyte in project name and path, in name of the file and in file contents - and have such a project in the default utf-8 project encoding - another project (not the same one) - in euc-jp encoding. ken.frank@sun.com
1.) linux System Locale; Encoding = ja_JP (nb); EUC-JP-LINUX a.) project name and path with multibytes project encoding EUC-JP created a file containing multi bytes and with multibytes in name import with a message containing multibytes WORKS b.) project name and path with multibytes project encoding UTF-8 created a file containing multi bytes and with multibytes in name import with a message containing multibytes WORKS 2.) linux System Locale; Encoding = de_DE (nb); ISO-8859-1 a.) project name and path with multibytes project encoding ISO-8859-1 created a file containing multi bytes and with multibytes in name import with a message containing multibytes WORKS b.) project name and path with multibytes project encoding UTF-8 created a file containing multi bytes and with multibytes in name import with a message containing multibytes WORKS please provide an exact scenario how to reproduce: - locale under which you are running nb - project encoding - does the import from the cmd line with the same locale setting work? - maybe it would help if you would send over such a project regards
same scenrio as original issue, but here is 2 scenarios 1. ja locale solaris, java project with a main class and a java class mbyte in proj path, project name, file names, pkg names and in code project encoding is utf-8, the detault. the errors described in this issue still occur. 2. same as 1 except a project with euc-jp encoding same problems. attached is a zip with each project, project with #98 is the one with utf-8 encoding, 100 is with euc-jp. svn being used is from a solaris pkg attached. ken.frank@sun.com
Created attachment 50453 [details] svn zip of solaris pkg
i was able to import both attached projects on Product Version: NetBeans IDE Dev (Build 071008) Java: 1.6.0; Java HotSpot(TM) Client VM 1.6.0-b105 System: SunOS version 5.11 running on sparc; eucJP-open; ja_JP (nb) svn, version 1.4.4 (r25188) compiled Aug 15 2007, 05:02:11 worksforme
i would suggest you try if the import with cmd lien client works for you
removing incomplete and providing info requested - this is for if path to the project has multibyte in it. using commandline, if in en locale, the same error msg is seen as when using nb. if in ja locale, dont even get the far, some error all in japanese if in ja utf-8 locale, get the same error msg as described here Safe data '/home/project/' was followed by non-ASCII byte 175: unable to convert to/from UTF-8 But it might be the svn that I have on solaris, as we have discussed,since using the svn from sunfreeware and being in ja locale on solaris, its not seen by you. I think we can see if any user reports about it. ken.frank@sun.com
rather than reopen similar issue for mac, where it is seen also, let me ask about it here and see if symptoms might be different so that it would be separate issue see attached svnmac.gif for gif with output window and svn dialog. BTW, problem is still seen on my solaris, but I realize not seen on developers solaris. ken.frank@sun.com
Created attachment 58451 [details] image
*** Issue 142600 has been marked as a duplicate of this issue. ***
Tomas, I'm sorry; I thought I'd reviewed all svn module i18n issues to see if one had been filed on this, but missed this one and saw the one on commit, thus thats why filed this one. I'll review this one and provide the information and do comparisons again about command line vs in nb. ken.frank@sun.com