Recursive diff ignores encoding errors

[tillman]

I did a recursive diff between a label and the current repository version on project that contains two binary files (dll's) that I had just checked in and that were newer than the label I was diff'ing. The diff returned 0 differences. When I did a label vs. current version diff on the dll that I had just checked in, I got an encoding error (see attachment). Could this mean that the recursive diff ignores or doesn’t report file-level errors found during the diff?

Note that Vault did detect that the dll's in my working folder had changed since they appeared in the Pending Change Set view before I checked them in.

[jeffhostetler]

DiffMerge does not support side-by-side file diffs of binary files.
DiffMerge's file window is a line-oriented, text-based comparison.

The NUL character message indicates that the file is either binary
or contains data in a character encoding different from the one
selected (such as utf16).

The file cannot be imported because NUL isn't a valid unicode
character. All files get converted from their original encoding
(code page n, latin-n, utf-n, etc) on disk into unicode in memory.
When NUL's are present, this conversion fails.

DiffMerge's folder window *will* scan both binary and text files
and report when there are differences, but it is only doing a
memcmp() on the raw bytes in each pair of files.

I hope this answers your question.
jeff