Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: domain of brane@wandisco.com designates
 209.85.212.180 as permitted sender)
Message-ID: <544CCB41.6080500@wandisco.com>
Date: Sun, 26 Oct 2014 11:21:53 +0100
From: =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= <brane@wandisco.com>
Organization: WANdisco
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
 rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: dev@subversion.apache.org
Subject: Re: svn:mime-type arbitrary parameters
References: <544BF1A4.6020604@seantek.com> <544C4763.1060709@wandisco.com>
 <544C7D69.6010409@seantek.com>
In-Reply-To: <544C7D69.6010409@seantek.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

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

That will be exposed to the browser in the Content-Type header, and the
Subversion client, which uses svn:mime-type for its own purposes, will
ignore any content type parameters (that is, anything after the semicolon).

The restriction here is that Subversion restricts the value of the
svn:mime-type property to be in the ASCII; which, incidentally, is
required by RFC2045 (see: https://www.ietf.org/rfc/rfc2045.txt section 5.1).

This may be unwieldy, as you say in your original post, but it's the
only way that works.

-- Brane