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
