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

Re: Forcing svn:eol-style=native on files with "binary" mime types?

From: Andreas Keil <rien_at_nurfuerspam.de>
Date: 2005-09-22 09:31:35 CEST

"Aleksey Nogin" <aleksey@nogin.org> wrote:
>I have a number of files that should use native eols, but should not be
> merged by subversion. It turns out that if I _first_ mark these files
> with a "non-text" mime-type, then subversion refuses to accept
> eol-style=native on them, complaining:
>
> svn: File 'foo' has binary mime type property
>
> [...]

Hi Aleksey,

I raised this question in the discussion news:dftcdd$5fq$1@sea.gmane.org
titled "Interpretation of SVN MIME type property" in this group, too, but it
seems that most people won't see the problem of connecting MIME types to eol
styles. I personally think that this shouldn't be tried at all, since the
SVN developers will never catch up with upcoming MIME types and there are
lots of file types which will never get a MIME type assigned.

That's why I proposed to remove this connection and to introduce a new value
for the svn:eol-style property which would tell SVN to stick with the
original eol markers. I'm not sure if a new keyword would be needed as I'm
not really sure about SVN's behaviour on files without the svn:eol-style
property. But at least it would be consistent to add one named "binary",
"original", "keep", or sth. like that.

Please help me in removing SVN's bug of assuming application/* to contain
binary data, as this is *really* a bug, no matter what one thinks about
possible solutions to the eol problem.

Thanks,
Andreas.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 22 09:35:48 2005

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.