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

Hanjy <hanjingyu@gmail.com> writes:
> Sorry, attached the patch file:

Thank you.

But, did you actually read the URL I sent? Your patch was attached as
application/octet-stream, was not targeted from the top of the working
copy, and still contains no log message. Again, that URL is:

   http://subversion.tigris.org/mailing-list-guidelines.html#patches

Regarding your patch:

> Index: subst.c
> ===================================================================
> --- subst.c (revision 17625)
> +++ subst.c (working copy)
> @@ -222,8 +222,35 @@
> break;
> case 'D': /* long format of date of this revision */
> if (date)
> - svn_stringbuf_appendcstr (value,
> - svn_time_to_human_cstring (date, pool));
> + {
> + const char human_timestamp_weekday_names [7][4] =
> + {"Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat"};
> + const char human_timestamp_month_names [12][4] =
> + {"Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug",
> + "Sep", "Oct", "Nov", "Dec"};
> +
> + apr_time_exp_t exploded_time;
> + const char *human;
> +
> + apr_time_exp_lt (&exploded_time, date);
> +
> + human = apr_psprintf (pool,
> + "%04d-%02d-%02d %02d:%02d:%02d %+03d%02d (%s, %.2d %s %.4d)",
> + exploded_time.tm_year + 1900,
> + exploded_time.tm_mon + 1,
> + exploded_time.tm_mday,
> + exploded_time.tm_hour,
> + exploded_time.tm_min,
> + exploded_time.tm_sec,
> + exploded_time.tm_gmtoff / (60 * 60),
> + (abs (exploded_time.tm_gmtoff) / 60) % 60,
> + human_timestamp_weekday_names[exploded_time.tm_wday],
> + exploded_time.tm_mday,
> + human_timestamp_month_names[exploded_time.tm_mon],
> + exploded_time.tm_year + 1900);
> +
> + svn_stringbuf_appendcstr (value, human);
> + }
> break;
> case 'r': /* number of this revision */
> if (rev)

I don't think this really solves the problem. It assumes that
straight ASCII is acceptable in the file's encoding; in other words,
it assumes that one *particular* (hardcoded!) locale is correct. But
if we know nothing about the encoding of the document, we cannot
assume that the encodings you use above are right for that document.

That's why my comment in this issue implies it's hard to solve :-).

A good strategy would be to propose a full solution here, just a
description, and let the development community help you design it, and
then submit a patch. This avoids wasted time for you.

Best,
-Karl

-- 
www.collab.net  <>  CollabNet  |  Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org