Comment 24 for bug 593560

vila pointed out to me on IRC that we already truncate mtimes (and ctimes) to 1s resolution. (That reminded me that we introduced that behaviour to guard against exactly this sort of bug in the kernel.)

So that probably rules out bug 613873 as being involved. But something still smells fishy. Can you try running "bzr status" twice in a row, and tell us if the second time is still 25s? Basically for making sense of "bzr status" timings it helps to know how many files have changed since the last bzr operation, and whether the tree and repo would still be in the OS cache or not. It would be good to get a baseline value for hot cache + nothing changed, which should incur no physical disk IO.

As a data point, if I touch every file in my gcc-linaro tree (find . | xargs touch), 'bzr st' takes < 9s to run with a hot cache (it has to revalidate the file contents and rewrite the dirstate).