Bug 117107 - I18N - solaris - can't import into repos if non ascii in project name or path
I18N - solaris - can't import into repos if non ascii in project name or path
Status: RESOLVED WORKSFORME
Product: versioncontrol
Classification: Unclassified
Component: Subversion
6.x
Sun All
: P2 (vote)
: TBD
Assigned To: issues@versioncontrol
issues@versioncontrol
: I18N, RELNOTE
: 142600 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-09-29 19:01 UTC by Ken Frank
Modified: 2008-08-02 01:02 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
:


Attachments
log file (67.72 KB, text/plain)
2007-10-02 15:12 UTC, Ken Frank
Details
gestures file (576.12 KB, text/plain)
2007-10-02 15:30 UTC, Ken Frank
Details
svn zip of solaris pkg (79.71 KB, application/octet-stream)
2007-10-09 00:18 UTC, Ken Frank
Details
image (116.48 KB, image/gif)
2008-03-16 18:42 UTC, Ken Frank
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ken Frank 2007-09-29 19:01:38 UTC
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.
Comment 1 Ken Frank 2007-09-29 19:08:55 UTC
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)
Comment 2 Tomas Stupka 2007-10-02 11:09:08 UTC
could you please attach your messages.log from a NB session you got this problem

thanks
Comment 3 Ken Frank 2007-10-02 15:12:41 UTC
Created attachment 49997 [details]
log file
Comment 4 Ken Frank 2007-10-02 15:13:04 UTC
log file is attached.
Comment 5 Tomas Stupka 2007-10-02 15:18:02 UTC
sorry, but i don't see the reported exception in the log file :(
Comment 6 Ken Frank 2007-10-02 15:30:44 UTC
Created attachment 50003 [details]
gestures file
Comment 7 Ken Frank 2007-10-02 15:32:02 UTC
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
Comment 8 Ken Frank 2007-10-03 16:40:25 UTC
removing incomplete keyword.
Comment 9 Tomas Stupka 2007-10-08 10:46:00 UTC
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
Comment 10 Tomas Stupka 2007-10-08 10:55:21 UTC
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

Comment 11 Tomas Stupka 2007-10-08 10:58:06 UTC
> 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. 
Comment 12 Ken Frank 2007-10-08 17:00:48 UTC
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
Comment 13 Tomas Stupka 2007-10-08 17:17:26 UTC
e.g. 
svn import [your_projects_full_path] file:///data/subversion/[your_projects_name]

Comment 14 Tomas Stupka 2007-10-08 17:29:43 UTC
how was the project created? with 6.0 or maybe with 5.5?
Comment 15 Ken Frank 2007-10-08 17:41:14 UTC
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
Comment 16 Tomas Stupka 2007-10-08 18:02:26 UTC
just for the record:

this workls for me on linux
System Locale; Encoding = ja_JP (nb); EUC-JP-LINUX
Comment 17 Ken Frank 2007-10-08 18:22:17 UTC
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
Comment 18 Tomas Stupka 2007-10-08 18:52:02 UTC
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

















Comment 19 Ken Frank 2007-10-09 00:14:03 UTC
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
Comment 20 Ken Frank 2007-10-09 00:18:00 UTC
Created attachment 50453 [details]
svn zip of solaris pkg
Comment 21 Tomas Stupka 2007-10-09 18:20:52 UTC
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
Comment 22 Tomas Stupka 2007-10-09 18:23:33 UTC
i would suggest you try if the import with cmd lien client works for you
Comment 23 Ken Frank 2007-11-15 16:36:34 UTC
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
Comment 24 Ken Frank 2008-03-16 18:42:00 UTC
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
Comment 25 Ken Frank 2008-03-16 18:42:39 UTC
Created attachment 58451 [details]
image
Comment 26 Tomas Stupka 2008-08-01 19:34:49 UTC
*** Issue 142600 has been marked as a duplicate of this issue. ***
Comment 27 Ken Frank 2008-08-02 01:02:05 UTC
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


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