If it is the original SVN which is in error, it could be that SVN fixes it up on checkout and hence we've never noticed it before. That implies the need for a tool which can grok the SVN repo directly for mismatched EOLs.
Niall, the issue is that SVN treats most SVG files as binary currently. As far as I'm aware, it does not fix anything up on checkout.
I looked into this problem over the weekend. You're somewhat right: the cause is that the (per-file) svn:eol-style property in the Boost SVN repo is not necessarily consistent with the list specified at https://svn.boost.org/trac/boost/wiki/BoostSubversion, and because the .gitattributes ryppl is using is an exact duplicate of https://svn.boost.org/trac/boost/wiki/BoostSubversion, this introduces EOL inconsistencies. I didn't observe your statement that SVG is mostly treated as binary, it seems to be more that most SVG in some particular library is either mostly one way or another but not consistently so. This isn't just a SVG problem: bootstrap.bat in the root directory has the wrong svn:eol-style for example! Options: 1. If we don't care that checkouts from git of old revisions may have incorrect EOLs, we can commit a fix to all affected files in SVN HEAD to ensure their svn:eol-style exactly matches what https://svn.boost.org/trac/boost/wiki/BoostSubversion says it should be. 2. If we do care that checkouts from git any revision are always correct, we'll need to do some monkeypatching during the svn to git conversion process (i.e. check for incorrectness, and fix). Niall --- Opinions expressed here are my own and do not necessarily represent those of BlackBerry Inc.