On 26.10.2014 16:06, Sean Leonard wrote:
> On 10/26/2014 3:21 AM, Branko Čibej wrote:
>> On 26.10.2014 05:49, Sean Leonard wrote:
>>> On 10/25/2014 5:59 PM, Branko Čibej wrote:
>>>> On 25.10.2014 20:53, Sean Leonard wrote:
>>>>> It appears that the matter was not fully resolved. svn:charset seems
>>>>> to enjoy de-facto use.
>>>> If anyone is using svn:charset, they're violating our rules. The svn:
>>>> namespace is reserved for property names defined by Subversion, and
>>>> we've not defined that name. So ... using that name is likely to cause
>>>> problems at some point.
>>> Ok. So I guess the issue of how Subversion encodes a particular
>>> character set/character encoding is still "live"?
>> Well, Subversion doesn't "encode" anything; but for the purpose of
>> serving content straight from the repository through an HTTP server, the
>> established way to define the character set is to add the tag to the
>> svn:mime-type property, e.g.:
>> svn propset svn:mime-type 'text/plain; charset=UTF-8' file...
> Actually I have a different proposal: what if the property name is the
> parameter, prefixed with "svn:mime-type:", and the property value is
> the UTF-8 encoded parameter value?
> For example:
You must be confusing Subversion with some Web content management system. :)
The fact that the svn:mime-type property is usable in any way for
serving content from the repository is more or less an accident; it's
definitely not a design goal. What you propose would have zero benefit
for Subversion as a version control system but less than trivial
maintenance costs, so it's not likely to ever happen.
> Are there other places where this property is parsed or interpreted?
It's used by mod_dav_svn to populate Content-Type; but, as I said,
that's not the purpose of the property.
> OK. How does Subversion restrict the value to US-ASCII?
It turns out I was wrong about that; we don't restrict the value to
US-ASCII. See svn_mime_type_validate in subversion/lbsvn_subr/validate.c.
Received on 2014-10-26 19:35:46 CET