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

Re: [PATCH] Issue 2332, "$Date$" Keywords always expand with their UTF-8 content

From: Peter N. Lundblad <peter_at_famlundblad.se>
Date: 2005-12-07 09:24:27 CET

On Tue, 6 Dec 2005, Daniel Rall wrote:

> On Wed, 07 Dec 2005, Hanjy wrote:
> ...
> > > > I didn't change the function svn_time_to_human_cstring in
> > > > libsvn_subr/time.c, there are several places to call the function, I don't
> > > > know whether these need to change. so I only changed the keyword_printf
> > > > function in libsvn_subr/subst.c, I hope who can do a full repair than me.
> ...
> For posterity's sake, I'll mention that this patch only addresses the
> Date keyword portion of issue 2332, and and not the similar problems
> for other keywords like Id.
> The Date portion of issue 2332, "Keyword expansion in non-UTF8
> documents results in mixed charsets", is addressed by removing use of
> apr_strftime(). apr_strftime() delegates to strftime() under the
> covers, which -- given
> libsvn_subr/time.c:human_timestamp_format_suffix -- the man page
> indicates formats each element "name according to the current locale".
> The patch replaces apr_strftime() with a hard-coded set of day and
> month abbreviations, which are in English only.
Oh! I think the correct solution is to recode the whole keyword string
when replacing it in the file. The problem is that we don't know the
encoding of the file. Using the user's locale encoding might more often
be correct than using UTF8.. I used the same philosophy when changing
conflict makers from UTF8 to the native encoding.

We really need to allow users to store the encoding of a file via some
property, but that's a bigger issue that I would like to come back to some


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Dec 7 09:25:30 2005

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.