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.

Bug 122284 - I18N - Subversion error because of comment encoding
Summary: I18N - Subversion error because of comment encoding
Alias: None
Product: versioncontrol
Classification: Unclassified
Component: Subversion (show other bugs)
Version: 6.x
Hardware: Macintosh Mac OS X
: P3 blocker with 2 votes (vote)
Assignee: issues@versioncontrol
Keywords: I18N, RELNOTE
: 147197 (view as bug list)
Depends on:
Reported: 2007-11-19 13:19 UTC by johanandren
Modified: 2008-09-15 15:45 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

logfile with error (51.77 KB, text/plain)
2007-11-19 13:54 UTC, johanandren
Screenshot of error (249.79 KB, image/png)
2007-12-14 12:08 UTC, johanandren

Note You need to log in before you can comment on or make changes to this bug.
Description johanandren 2007-11-19 13:19:04 UTC
I get the following error from svn when trying to commit with swedish characters (åäö) in the comment.

Command output:

==[IDE]== 2007-nov-19 14:12:51 Committing...
ci -N --force-log -F /tmp/svn_message_55249 -m Beroende på NativeLoader-bibliotek. Småändringar här och var. --non-interactive --config-dir 
/Users/johan/.netbeans/6.0rc1/config/svn/config --targets /tmp/svn_checkin_55250
svn: Commit failed (details follow):
svn: Can't convert string from native encoding to 'UTF-8':
svn: Beroende p?\195?\165 NativeLoader-bibliotek. Sm?\195?\165?\195?\164ndringar h?\195?\164r och var.
==[IDE]== 2007-nov-19 14:12:57 Committing... finished.

Have tried to set the LC_CTYPEL to 'sv_SE.UTF-8' and 'en_US.UTF-8' without any success.
Comment 1 Tomas Stupka 2007-11-19 13:27:12 UTC
> Have tried to set the LC_CTYPEL to 'sv_SE.UTF-8' and 'en_US.UTF-8' without any success

could you please attach your messages.log file


Comment 2 johanandren 2007-11-19 13:54:33 UTC
Created attachment 53200 [details]
logfile with error
Comment 3 Tomas Stupka 2007-11-20 19:17:55 UTC
the local seems to be ok. could you, please, try to commit from the command line, if the error also appears there?

Comment 4 johanandren 2007-11-21 08:54:20 UTC
When using the subversion client from the commandline it works fine.

(This is what I have been doing to work around the problem, but it also means i have to do svn add and such manually)

LC_CTYPE, the L was a typo. I also tried setting LC_ALL just to be sure.
Comment 5 pinheiro 2007-11-23 16:30:02 UTC
I do have the same problems, and with NB 5.5.1 I did alter the netbeans executable
(/Applications/ and included  "export LC_ALL=pt_BR.UTF-8" (without
quotes) to work with brazilian portuguese input, as

In NB 6.0 RC2, when trying to commit with the message "Test: á é í ó ú ç ã  (a e i o u c a)":

svn: Commit failed (details follow):
svn: Can't convert string from native encoding to 'UTF-8':
svn: Test: ?\135 ?\142 ?\146 ?\151 ?\156 ?\141 ?\139  (a e i o u c a)
Comment 6 Ken Frank 2007-12-13 15:54:18 UTC
submitter, can you see if this is related to what was reported in 117017 ?

also, what platform are you on ?
and can you do other things of subversion inside nb besides commit ?
Comment 7 johanandren 2007-12-14 08:29:59 UTC
All other svn functionality works as expected, checking in changes works if I use only ascii characters.

I'm on OsX 10.5, but the problem was present in 10.4

I have looked ad issue 117017 ("Refactoring Push Down do not modify the original class") but I cannot see how it is related to this. Perhaps I have 
misunderstood you?
Comment 8 pinheiro 2007-12-14 10:23:44 UTC
I'm using OS X 10.4.11.
I can do everything else inside netbeans (checkout, update, switch...).

I think it is not related to 117017, as this is not related to any refactoring...
Comment 9 yotta 2007-12-14 10:58:40 UTC
This problem also happens with me when I try to commit(Using the Tortoise SVN all work perfect).
I' am using: Netbeans 6 (Final), JDK 6, Windows XP SP2

I Wrote: 'Implementação'

This error occurs:
Safe data 'Implementa' was followed by non-ASCII byte 231: unable to convert to/from UTF-8

==[IDE]== 14/12/2007 05:36:46 Committing...
ci -N --force-log -F C:\WINDOWS\TEMP\svn_message_42306 -m Implementação da regra ModeloCurso --non-interactive
--config-dir C:\Documents and Settings\gustavoh\.netbeans\6.0\config\svn\config --targets C:\WINDOWS\TEMP\svn_checkin_42307
svn: Commit failed (details follow):
svn: Safe data 'Implementa' was followed by non-ASCII byte 231: unable to convert to/from UTF-8
==[IDE]== 14/12/2007 05:38:57 Committing... finished.
Comment 10 Tomas Stupka 2007-12-14 11:09:27 UTC

i think i have a fix for this, the problem is that i can't reproduce:(

yotta, johanandren, pinheiro:
is it ok if i mail you a jar file so you may try for yourself if it works?


Comment 11 johanandren 2007-12-14 12:08:19 UTC
Created attachment 54260 [details]
Screenshot of error
Comment 12 johanandren 2007-12-14 12:10:47 UTC
The error is still there with the replacement svnClientAdapter

The checkin on the screenshot is with the text "Ändrat portnummer på continuum och svn-browsaren i pom:en"
Comment 13 Tomas Stupka 2007-12-14 12:20:08 UTC
your output windows lists the used svn command - see the second line. something like 
"ci -N --force-log ..."

could you please try to run it from the commandline - "svn [the_line_from_your_output_window]"

the command refers to some temporary files witch get deleted after netbeans exit, so if you already closed your NB
session 1.) you have to reproduce the problem again
2.) copy the listed command
3.) and run it from the cmd line (before you close NB)

Comment 14 johanandren 2007-12-14 15:20:50 UTC
Command copied and run from console (had to remove --non-interactive) works:

Macintosh:trunk johan$ svn ci -N --force-log -F /tmp/svn_message_37749 --config-dir /Users/johan/.netbeans/6.0/config/svn/config --targets 
Authentication realm: <http://smith:80> DABY
Password for 'johan': 
Sending        pom.xml
Adding         src/main/java/se/databyran/external
Adding         src/main/java/se/databyran/interinfo/ear/
Adding         src/main/java/se/databyran/interinfo/ear/
Sending        src/main/java/se/databyran/interinfo/ear/
Sending        src/main/java/se/databyran/interinfo/ear/
Sending        src/main/webapp/WEB-INF/web.xml
Adding         src/main/webapp/admin.jsp
Sending        src/main/webapp/index.jsp
Transmitting file data ........
Committed revision 1220.

Comment 15 Tomas Stupka 2007-12-14 16:13:42 UTC
hm, to be honest i'm running out of ideas.
maybe one more thing - we had some environment settings related issues on mac when NB where started from a desktop icon.
So the question is if you are able to reproduce when starting NB from the shell?

Comment 16 Ken Frank 2007-12-14 16:46:56 UTC
sorry about confusion of other issue, it was 117107 on solaris.

thats the topic of 117107, I've gotten this msg on solaris mentioned below when using a different svn than was used
by some others.
svn: Safe data 'Implementa' was followed by non-ASCII byte 231: unable to convert to/from UTF-8

for the situation on pc, setting 
APR_ICONV_PATH is sometimes a solution for some of these situations; not sure if it applies to
this one.
Comment 17 johanandren 2007-12-18 15:11:46 UTC
If i start netbeans from a terminal instead of by it's icon the encoding problem goes away (that is '/Applications/NetBeans/NetBeans\')!

Comment 18 Ken Frank 2007-12-18 17:46:12 UTC
removing incomplete keyword since I think all needed info has been supplied.
Comment 19 Tomas Stupka 2008-01-02 09:56:15 UTC
this looks similar to a problem described in

what output do you get when running the "locale" command from your shell?

Comment 20 johanandren 2008-01-07 18:36:58 UTC
jbook:~ johan$ locale

I have also tried using  "LC_ALL=sv_SE.UTF-8" without success.
Comment 21 Ken Frank 2008-04-14 22:22:22 UTC
to issue filer - does the problem still happen for you using
nb6.1 ? 

to developers, seems like this would be a p2 since seems to block
using specific functionality of the module ?
Comment 22 johanandren 2008-04-15 08:16:43 UTC
In NetBeans 6.1RC1 the problem still does happen.
Comment 23 Ken Frank 2008-04-16 17:49:29 UTC
to dev team, is it something that could/should be considered
for 6.1 patch release vs fixing in 6.5 ?
Comment 24 Tomas Stupka 2008-04-16 21:58:57 UTC
sorry for reacting so late, i totally lost track of this issue. My bad.

as i already mentioned in a post above:
this is a similar problem like in

the problem here is that when nb gets started from the desktop (even with a correct locale as we can see in the log
file) it runs the svn excutable in a new shell which, for some os specific reasons, doesn't inherit the complete
environmental settings. It looks like osx doesn't propagate all settings to the command line and vice versa.
e.g. setting the locale in the os preferences doesn't change the locale in a newly opened shell. 
To be honest, i have no idea if this is a osx feature a misbehavior or only a wrong os setup which may be changed so
that the locale (sv_SE) is also set for each new shell instance. Because that would be the clean and correct solution
for your problem. 

The only way it seems to work is to set the locale in a shell and then to start nb from the shell. I hope this isn't
bothering you a lot as at this moment i don't see a simple way how to get around this and, unfortunately for you, i'm
going to set this as wontfix. 

We could indeed look for a way how to workaround it but the thing is that we plan to abandon the commandline client in
the near future and this problem should be gone then. 
Comment 25 Ken Frank 2008-04-21 20:11:54 UTC
adding keywd for relnote, since users on mac don't usually need to deal with
unix commandline, which is stated below as way to avoid the problem - to
set locale or other locale vars in terminal and start netbeans there.

to developers - can you provide me with relnote text and workaround
and on what specific platform/os - and I can get it into rel notes.
Comment 26 Tomas Stupka 2008-09-15 15:41:32 UTC
with svn > 1.5 this issue shouldn't appear anymore
Comment 27 Tomas Stupka 2008-09-15 15:45:41 UTC
*** Issue 147197 has been marked as a duplicate of this issue. ***