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

Re: svn:charset

From: David Glasser <glasser_at_davidglasser.net>
Date: Tue, 8 Jul 2008 16:00:10 -0700

On Tue, Jul 8, 2008 at 8:58 AM, Karl Fogel <kfogel_at_red-bean.com> wrote:
> "David Glasser" <glasser_at_davidglasser.net> writes:
>> On Fri, Jul 4, 2008 at 1:30 AM, Dag-Erling Smørgrav <des_at_des.no> wrote:
>>
>>> - Like it or not, svn:charset is already in use; formalizing it is the
>>> path of least resistance (though I understand your annoyance at the
>>> encroachment on what I understand is a reserved namespace)
>>
>> I don't think that the Subversion project needs to negotiate with
>> hostage-takers.
>
> Heh :-).
>
> But, as much as I enjoyed David's comment, the OP's sentiment is right:
> however we got here, here is where we are. (Besides, he wasn't
> proposing negotiation.)

In all seriousness, though, I highly suspect that any group of
projects that are so lax that they don't even bother to understand
that svn:* are the only properties they *aren't* allowed to use would
also have failed to resolve all the issues discussed in this thread.
In that case, using svn:charset for a potential new property would be
the absolute *worst* thing to do, since it would conflict with
poorly-specified prior use.

Anyway, if the main problem with the svn:mime-type solution is that
it's annoying to parse (which is true), then why don't we just add an
svn API that extracts the charset= from a given mime-type string? (I
guess there's still the autoprops issue, but perhaps there is a more
general fix to autoprops that could deal with this.)

--dave

-- 
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-07-09 01:00:31 CEST

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.