[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Locale problem: Can't convert string from native encoding to 'UTF-8'

From: David Kramer <david_at_thekramers.net>
Date: 2005-09-07 17:29:45 CEST

On Tue, September 6, 2005 3:30 pm, David Kramer wrote:
> Background:
> - I'm running svnserve 1.1.0 on my old server using berkeley back end for the
> repository. (SuSE 9.0)
> - I just built a new server, now running svnserve 1.2.1, using fsfs for the
> repository (SUSE 9.3, with subversion server and libraries updated from
> ftp.suse.com/pub/projects)
> - I dumped the repositories from the old server and loaded them on the new
> server.
> - I twiddled my router so now all svn:// requests went to the new server.
> After doing that, I was able to check out and in with the new repository (this
> is as of a day or two ago). Now, I get the following error:
> david@deepthink:/devel/agilerules/web/private/htdocs/worknotes> svn commit -m
> "web private: removed worknotes/htmlunit"
> Deleting worknotes/htmlunit
> svn: Commit failed (details follow):
> svn: Can't convert string from native encoding to 'UTF-8':
> @?\217?d?\14?\184?\174
> - All files and filenames in version control are plain text or OpenOffice
> documents. All plain text files are normal ASCII US characters.
> Now, I did some RTFM and some STFW, and noticed that (1) part of the 1.2
> series changes was added localization, and (2) the way you set the
> localization of the server is by exporting LANG to the correct setting in the
> script that starts up svnserve, and I've now done that, setting/exporting both
> LANG and LC_ALL to en_US.UTF-8 in /etc/init.d/svnserve. This did not seem to
> help.
> We tried upgrading the client to the latest, and that didn't seem to help
> either.
> After changing the locale on svnserve, do I need to do the load operations
> again?
> Do I need to make new working copies?
> One bit of funkyness is that I had libapr0-2.0.53-9, to match
> apache2-2.0.53-9.2. The subversion-server-1.2.1-1.1. said to install
> libapr0-2.0.54-7.1.i586.rpm, but when I did so, apache would segfault on all
> client requests, so I reverted to libapr0-2.0.53-9. Both apps seemed to work
> after that, but I'm not sure if that's involved or not. Maybe whether using
> that version of svnserve with that version of of libapr is a separate
> question.
> Thanks. We can't check in anything until this is resolved, so please get back
> to me with any tips as soon as possible. Thanks.

We've tried a few more things, with no luck.

- I tried checking out a fresh working copy, but I got the same "Can't convert
string from native encoding to 'UTF-8'"

- I tried wiping out the repository and reloading it, now that svnserve is
running UTF-8, but reloading failed, with
"uninew:/data/subversion/agilerules # svnadmin load web <
<<< Started new transaction, based on original revision 1
     * adding path : devel ... done.
     * adding path : live ... done.
svnadmin: Valid UTF-8 data
followed by invalid UTF-8 sequence
(hex: a0 d1 07 08)

Is there a way to convert the dump to UTF-8 (it's all US ASCII, AFAIK)?

Is there a way to load the dump as native, and get the svnserve client to work
with it?

Thanks again. We at a dead stop over this.

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Sep 7 17:31:40 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.