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. -- Brane
