Greg Thomas <firstname.lastname@example.org> writes:
> >Depending on your OS, here is a one liner that should get you what you
> >want, then cut the end off and run that through xargs again to set the
> >need-lock property.
> >find . -type f | grep -v .svn | xargs svn propget "svn:mime-type" 2>/dev/null | grep application/octet-stream$
> That's fine for application/octet-stream files, but what about other
> mime-types - GIFs, PNGs, Word, Excel, etc. I'd need an exhaustive list
> of all binary types. Given that svn has already identified the file as
> binary when it was added, I was hoping to use that identification.
The concept of "binaryness" is a little more complicated in Subversion
that is is in (say) CVS.
The auto-detection of binaryness that Subversion tries to do at
add/import time simply results in the property "svn:mime-type" being
set on the file, with value "application/octet-stream".
On the other hand, if *you* set the svn:mime-type property manually,
and its value begins with anything other than "text/", then Subversion
will treat the file as binary. Well, that's a bit of an
oversimplification: Subversion also treats "image/x-xbitmap" and
"image/x-xpixmap" as textual types, and maybe more will be added in
the future. But the point is, Subversion starts out assuming that a
mime type represents binary data, and then makes exceptions.
Now, for files with no svn:mime-type property, Subversion behaves in a
carefully two-minded way. Subversion won't do any keyword
substitution or newline conversion (both of which are usually bad news
in binary files) unless you set the svn:keywords or svn:eol-style
properties explicitly. On the other hand, Subversion will try to show
diffs for such a file during 'svn diff', and will try to show
line-by-line attribution as part of 'svn blame', both operations that
normally only make sense for text files. The reason for this is that
we don't want to force developers to set an svn:mime-type on all their
source code files just to get such common operations working -- but on
the other hand, we *definitely* don't want to munge the actual data in
the files without some indication from the user that that's okay.
If the FAQ doesn't already have an entry for "binary files",
explaining all this, it probably should. Now comes the part where I
try to seduce you into helping out: would you like to see what
http://subversion.tigris.org/faq.html says on this subject, and
produce a patch if needed?
and the source code for the FAQ is here:
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Thu Jun 2 19:11:16 2005