On Wed, Oct 06, 2004 at 08:52:33PM +0100, Philip Martin wrote:
> John Peacock <email@example.com> writes:
> > Archie Cobbs wrote:
> >> $ svn proplist -v generic-build.xml
> >> Properties on 'generic-build.xml':
> >> svn:mime-type : text/xml
> > ^^^^^^^^
> > This is the reason. Subversion considers XML files to be binary for
> > the simple reason that normal diff's won't always produce sensible
> > patches for XML files. They may be human-readable, but they are not
> > strictly text.
> No, text/xxxx files are non-binary, take a look at the function
> I guess what's happening is that one of the previous revisions of the
> file had a binary type; since blame checks the type of all the
> revisions involved having one revision with a binary mime-type will
> cause blame to fail. It's possible to restrict blame to only those
> revisions since the binary one, but that revision range may well not
> be enough to be useful.
> It's unfriendly for blame to behave this way. There is no way to
> modify the mime-type on old revisions, so if one accidentally commits
> a revision with a binary mime-type there is no way to correct it to
> enable blame to run. Perhaps blame should be changed so that only the
> current mime-type is used? Yes, that might allow a "real" binary file
> to erroneously take part in blame, but is that likely? I'd guess that
> when the mime-type indicates inconsistent "binaryness" the most likely
> explanation is an error in setting mime-type rather than a change in
> the format of the file contents.
If there are truly binary revisions, the blame information is likely
to be extremely unreliable.
I think the current approach is the safest. However, we may need
Do not include revisions that are binary according to
svn_mime_type_is_binary() in the blame calculations.
Include all revisions in the blame calculations.
We might want knobs like this in "svn diff".
In the same vein, GNU grep and diff use "-a/--text" to alter their
behaviour when confronted with binary data.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Mon Oct 11 16:51:52 2004