On Wed, 2009-11-18 at 12:16 +0100, Branko Čibej wrote:
> Julian Foad wrote:
> > Julian Foad wrote:
> >> I need to spend some time replying, late at night though it is.
> [...] (I'll respond to your original proposal later, but some quick
> notes here)
> > I wonder if I have missed some good reason not to update the built-in
> > list of MIME types that are considered "text". Just a constraint on the
> > available volunteer effort? I know it's not the 100% solution but it is
> > a 99% solution and UI am surprised we are not automatically starting
> > here.
> IIRC there are two reasons why we haven't updated that list:
> * doing it in code is a never-ending battle to catch up with IANA;
Sure, but while it's in the code that's not a reason not to keep
Meanwhile we should consider getting it out of the code, into some
configuration place. That is the direction in which my proposal heads.
> * there never was consensus for the "obvious" ones, for the simple
> reason that they're not always obvious -- e.g., consider
> application/xml, which sometimes can and sometimes can't be
> properly merged.
We don't need to try to be too clever. Either we decide that Subversion
shall do line-wise blame/diff/merge on these kinds of formats, or we
decide that it won't. People can plug in their own merge tools if they
need more advanced behaviour, so I think we should make these formats be
classified as "text" and therefore use blame/diff/merge on them.
> > Big con: Depends on auto-props, a mechanism which is not really good
> > enough for the task.
> ... because it's strictly client-side, *and* because it relies only on
> file names; which, BTW, is a serious problem with your proposal.
None of my proposals relied only on file names.
> But more about that in the "real" response.
Please first make sure you see my reply to B. Smith-Mannschott in this
thread, in which my text begins "Ah, yes, it is illogical".
Received on 2009-11-18 12:32:12 CET