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

Re: RFC: Am I being a hardass?

From: Dan Christian <dchristian_at_google.com>
Date: Thu, 7 Feb 2008 15:23:08 -0800

Is "is_binary" the right question?

Do you really want: do_newline_based_diffs and human_readable as separate
and independent flags?

I'm not proposing those as real tag names, but you get the idea.

For what it's worth, I think mime-type is the ioctl() of subversion. It
isn't clear what effect they are having, if there is a typo, or what values
could have an effect.

-Dan C

On Thu, Feb 7, 2008 at 4:14 AM, John Peacock <
john.peacock_at_havurah-software.org> wrote:

> I got involved in several discussion on users (which I know you don't all
> read
> regularly) about changing the various "application/xml*" types to be text
> by
> default, the longest of which is here:
> http://svn.haxx.se/users/archive-2008-02/0096.shtml
> I still believe that I'm right and that Subversion shouldn't have an ever
> increasing set of exceptions enshrined in svn_mime_type_is_binary() for
> all of
> eternity. I can pursue the not-so-simple task of adding a new
> svn:text-type (a
> boolean flag) that would override the normal MIME handling for purposes of
> diff/merge only.
> It would only be a small patch to add a whole bunch of exceptions to
> svn_mime_type_is_binary(). Is that the wiser course? Am I just being a
> pedant
> and a crank to insist that because some XML files should be treated as
> binary
> that we can't make that sort of overarching assumption, just because it
> will
> help most people?
> John
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
> For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-02-08 00:23:22 CET

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.