script to detect timestamp-mismatches (inefficiency) in (1.7) working copies?

Hi all,

As some of you may know, SVN uses filesize and last-mod-time of files
to optimize 'svn status' and other commands (if filesize and
last-mod-time of the file match those in the wc-metadata, the file is
assumed to be unchanged, and doesn't have to be read --- only if these
don't match, the file is read and checksummed, and compared with the
pristine file). If last-mod-times in the wc-metadata are out of sync
with those on the filesystem, a working copy becomes significantly
slower, because 'svn status' has to read all files in full to see
which were modified. Such timestamp mismatches can occur for instance
if the user (or some tool) 'touches' files, or if a working copy is
copied to another disk (this happens quite a lot in my company, f.i.
when developers get a new PC), or just recursively copied without
preserving last-mod-times.

Now, all is not lost if there are mismatches: 'svn cleanup' corrects
the last-mod-times in the wc-metadata (for all files which are still
identical to the pristine, the last-mod-time in metadata will be
updated). But the problem is that users are lazy, and they won't run
'svn cleanup' unless they know it's necessary / beneficial. So I'd
like to help them a bit by offering an easy way to detect if their
working copy contains a significant amount of timestamp-mismatches. A
bit like the 'Analyze' action in the Windows Defrag utility, which can
quickly report an estimated percentage of fragmentation, and based on
that suggests that you should or shouldn't defrag.

But I hate to reinvent the wheel, so: has anyone already written such
a script? I'm mainly interested in 1.7 working copies, but scripts for
1.6 may be interesting as well (we still have plenty of such working
copies lying around here).

Ideally this could become some builtin functionality of svn core, for
instance as an extra option to 'svn status'. Because 'svn status'
already does all the work required to detect these
identical-files-with-mismatching-timestamps (the files which it had to
read/compare in full (because the timestamp didn't match), yet were
completely identical). Maybe status could someday grow an option to
report those files (either a full list, or in some summarized way).

-- 
Johan