Karl Fogel <kfogel@newton.ch.collab.net> writes:
> cmpilato@collab.net writes:
> > Log messages are just revision properties, and Subversion claims
> > support for binary property values. So, even if, client side, log
> > messages were limited to 7bit (which I think should *not* happen), we
> > would still see this bug when someone used the upper ASCII characters
> > on some other property, e.g., a node's "svn:ignore" property value.
>
> A few words about that.
>
> Yeah, we should definitely support 8-bit chars in log messages. On
> the repository side, the revision property value is quite capable of
> storing it, because it can store any binary value, like Mike says.
>
> A person's $EDITOR can presumably write any binary value too.
Sure.
> The first problem in the pipeline is that the `log_msg' variable to a
> lot of internal functions is now `const char *' instead of stringbuf.
> As long as people stick to UTF-8, this is fine. If we want true
> binary log message support, we'll need to go back to stringbufs for
> that data (not a difficult change).
In general, I think we can special case the log messages in the client
side to be UTF-8 textual messages. I've got no problem with that.
> The next problem in the pipeline (based on what Ulf Tigerstedt
> encountered) is that the message has to be properly XML-encoded before
> being sent over the wire -- necessary whether UTF-8 or full binary.
The message already is being XML-encoded to some extent, in that '<'
and '>' and other such special chars are being converted to entity
representations, IIRC. I think all we need to do is to make sure that
all this stuff is first converted to UTF-8, and then just add the
"charset" XML attribute thingy that states that this particular XML
document is in UTF-8.
Am I remembering XML specs correctly?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jun 1 14:25:24 2002