svn:eol-style property

I have a question about how the svn:mime-type and svn:eol-style
properties interact.

For xml style sheets, a standard extension is .xsl and the proper
mime-type is application/xml. This is according to RFC 3023 and Python
2.2.2.

When I do the following:

$ svn propset svn:mime-type application/xml checkstyle2txt.xsl
property `svn:mime-type' set on 'checkstyle2txt.xsl'
$ svn propset svn:eol-style native checkstyle2txt.xsl
svn: Illegal target for the requested operation
svn: File 'checkstyle2txt.xsl' has binary mimetype property

I get the above error. The problem I have is that the file is text, and
I need to have svn:eol-style twiddling done when it is moved between
platforms.

This points out that relying on mime-type of 'text/.*' as an indicator
of a textual file is not 100%. The problem children I've found are all
the application/???+xml files mentioned in RFC 3023 and .sh shell
scripts. I bet there are more.

This became a problem for me because I'm writing a batch property
setting tool in Python. The tool uses the mimetypes.guess_type()
function. This function uses all the standard registered mime-type
mappings. My tool has a way to override the standards, but I'm not sure
I would want to do that.

Has anybody else had this issue? What workaround's have other folks
used?

I can workaround this by setting all the ones that I know to be a
problem to text/plain or text/application-xml or some such. However, I
think that this will bite me down the road.

BTW, I think I also discovered a bug in the propset code. The following
does not produce an error, but probably should since it is reciprocal of
the use case that did produce an error.

$ svn revert checkstyle2txt.xsl
Reverted checkstyle2txt.xsl
$ svn propset svn:eol-style native checkstyle2txt.xsl
property `svn:eol-style' set on 'checkstyle2txt.xsl'
$ svn propset svn:mime-type application/xml checkstyle2txt.xsl
property `svn:mime-type' set on 'checkstyle2txt.xsl'

Notice that I was able to set the svn:mime-type to application/xml even
though an incompatible property was already set. I consider this to be a
minor problem.

I'm really looking for a "proper" way around the issue I documented
above.

Richard
Received on Fri Apr 18 17:31:18 2003