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

Re: svn log behaves strangely when characters cannot be represented in the local charset

From: Karl Fogel <kfogel_at_red-bean.com>
Date: Mon, 18 Feb 2008 10:51:28 -0500

Vincent Lefevre <vincent+svn_at_vinc17.org> writes:
> Well, what you said earlier was ambiguous. But this isn't
> user-friendly. And you do *not* need a transliterating iconv to
> make it better. For instance,
> Test caractère non ISO-8859-1: ?\226?\134?\146
> would be better than:
> Test caract?\195?\168re non ISO-8859-1: ?\226?\134?\146
> i.e. transliterate only the characters that are not representable
> in the local charset.

No one here would ever argue against an unambiguous improvement, I
think :-). If you can make a patch that does that, that would be
great. (I'm assuming you're using "transliterate" above to mean
"convert to Subversion's ad hoc '?\NNN' representation".)

Branko is right that the current behavior is a deliberate choice,
though. We felt that log messages being printed to stdout were an
appropriate place for graceful degradation (as opposed to an error).

I'm not opposed to printing a warning to stderr as well, saying that
some log messages couldn't be fully converted; that way the user would
see the warning even if the log output were being redirected to a file.
If you have time to come up with a patch for that (independently of
the other change discussed above), that'd be great!


To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-02-18 16:57:34 CET

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

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