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

Re: "textual binary" MIME types (was Re: file locking and binary files)

From: Eric Gillespie <epg_at_pretzelnet.org>
Date: 2002-11-19 08:22:22 CET

Greg Hudson <ghudson@MIT.EDU> writes:

> I think everyone missed this. I don't think Subversion's list should be
> in the code (though I don't think it's a travesty that it lives there
> for now), and I don't think it should be in a config file. I think it
> should be in a data file under ${datadir} (or the Windows equivalent).

What does having two lists (one global, one per-repository; one
configurable, one not) buy you over a single, per-repository,
customizable list with default contents? Later you even refer
to the multiple-file setup as simpler? I don't see how.

> As a separate matter, it might be valuble to let people add
> local types (application/x-local-text-based-file-type). It
> doesn't really seem worth the complexity, but I wouldn't scream
> and yell about it. However:

It doesn't seem worth the complexity? It's going to be worth the
complexity to the people who *do* have local types. More
importantly, there are hundreds of MIME types today, many used
only for specialized purposes. Do you really think the svn team
will enumerate them all as well as correctly identify their
textual or non-textual status? What about the ones that are
inevitably forgotten? What about the ones that come out between
release (or, more likely, move from being an x-foo type to a foo
type).

> * I don't see any value in letting people remove items from
> the default list. If we added an item by mistake, that's a
> bug, and there's no requirement that users be able to work
> around bugs through configuration.

Like i asked earlier, what does the multiple file scenario buy
you over the single per-repository file? Even Karl agrees we do
want it configurable long-term, so why not just go with that
single file?

> * If someone does want to add a local type, it should not be
> done by editing the default list, because that would get in the
> way of Subversion upgrades. (Either an upgrade leaves the
> modified list alone, in which case new types known to
> Subversion don't show up, or the upgrade stomps on the modified
> list.)

Subversion upgrades have no business overwriting config files in
sysconfdir, much less in the repo config dir.

--
Eric Gillespie <*> epg@pretzelnet.org

Build a fire for a man, and he'll be warm for a day. Set a man on
fire, and he'll be warm for the rest of his life. -Terry Pratchett

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Nov 19 08:23:03 2002

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.