Re: Interpretation of SVN MIME type property

Hi Marcus,
you wrote:

> lets assume we follow your idea:
> 1. svn allows you to set svn:eol-style only on text files.
> 2. a user adds a pdf file. the current heuristic says text. yes that can
> happen with pdf.

Well, but then it's already corrupted on the server after the first commit,
right?

> 3. the user sets eol-style

To sth. like "binary", "original", or "keep" I assume.

> 4. the binary chunk at the end of the pdf gets corrupted.

It would only be corrupted if the user sets eol-style *after* having
committed and then updating again. And as I guessed before, this corruption
would have taken place then anyways. Please correct me if I'm wrong.

> the better idea is imho to allow the user to specify which mimetypes svn
> can/should handle as text.

I don't consider this a good option since MIME types seem to evolve all the
time and there are a lot of file extensions that don't have any MIME type
(esp. ones that are created by companies/individuals themselves which could
be binary as well as text). Handling unknown file types would then again
require setting some property manually (i.e. not relying on the file
extension and using autp-props).

> there is already a hard coded list for that. if you move that list into
> $HOME/.subversion/config you configure it at
> runtime. enough? once we get pushing server side configs to the client
> this process can be optimized for large teams.

You are talking about the SVN server, not a client, rigth? Unfortunately, I
don't have access to the server and therefore cannot look for this
hard-coded configuration :-(

> just my 2 cents
> darix

Thanks for your comments and help,
Andreas.

-- 
Mails to my e-mail address are usually discarded without even having been 
read, sorry. 
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org