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

Re: [PATCH] $LastChangedDate$ encoding

From: Peter Samuelson <peter_at_p12n.org>
Date: 2006-05-07 12:40:40 CEST

Resurrecting this issue.... This thread died 2 weeks ago; I'd like it
to be resolved one way or another. Could people comment further on
this and make some sort of decision?

I posted a patch for the $LastChangedDate$ keyword expansion in a WC,
to convert the expansion to the user's LC_CTYPE encoding. The
expansion is already performed in the user's native language; it is my
view that it is inconsistent to localise to a native language (and
native date format) but _not_ to a native encoding.

Furthermore, I view keyword expansion as an action specific to a WC.
The encoding should be consistent with filenames, which are also
specific to a WC.

Julian (and Malcolm, speaking on IRC) basically agree with me.

Brane argued for the status quo: use the user's own language and date
format, but render it in UTF-8. His point is that the desired encoding
of the file is not known, so a fixed default should be used.

Ivan argued for not localising the keyword expansion at all, but using
English with ASCII. [Note: I think that is reasonable, but perhaps not
easy to implement efficiently, as it may involve switching locales.]

The reason I bring this up is that I applied my patch to the Debian
unstable version of svn 1.3.1, and I got an angry complaint about it,
partly because my package is now inconsistent with official svn. I
view my patch as a bug fix, but if consensus is reached that the status
quo really is better, I'll seriously consider reverting the patch.

Further arguments: http://bugs.debian.org/290774

Thanks,
Peter

Received on Sun May 7 12:41:07 2006

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.