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

Re: "Can't recode string" again...

From: Ximon Eighteen <ximon.eighteen_at_int.greenpeace.org>
Date: 2006-01-08 10:54:41 CET

> So the hook script should have available to it the locale of the
> committer; that allows it to do things in that locale if that is the
> right thing to do, and it also allows it to use some other locale.

I've been following this discussion with some degree of confusion. In
fact I think I'm probably very confused. I *thought* for a while that
Gunter was saying that the encoding of data transmitted between anything
that talks to the repository server (apache, svnserve, whatever) should
be UTF-8 and then the repository server never needs to know about any
encoding other than UTF-8. The responsibility for handling encoding
conversion then falls on the "client" (thing talking to the repository
serving process) because the protocol over the wire stipulates UTF-8.

If this were the case the hook feature described above by Paul isn't
necessary because the message would go over the wire as UTF-8 and the
"client" would convert it to the "local" encoding.

So, I must assume that Subversion does NOT work this way, i.e. clients
are not responsible for converting to UTF-8 and the protocol over the
wire (so to speak) allows data in any encoding and the repository server
converts to UTF-8 if necessary. *If* this is true, is this because it
makes it easier to write a tool that talks to a repository server since
the tool need not know about converting between encodings? Am I
completely off the map and deserving of one of those white jackets and a
padded cell? :)

Ximon

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Jan 8 10:57:39 2006

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.