Comment 1 for bug 240508

So there are a couple of topics in this bug. I agree that showing first line of the commit for files and directories is a better use of real estate than a 1-second granularity timestamp :).

For directories though, it does not scale well to find the last change anywhere within the tree (for a few internals-reasons). Essentially on something like openoffice each request would have to access data on up to 60 thousand revisions to decide which change within a subtree was the most recent. What is shown for directories today is the last change made to the directory itself - was it renamed/reparented/added.

We have discussed on the bazaar list having both direct-change and transitive-change fields for directories but to date that hasn't eventuated.

Personally I'd hesitate to do a transitive change field in loggerhead unless it either already has a cache that can answer the question without potential size_history data access, -or- a switch to enable it for trees that are of modest size (like gnome.org projects that are individually quite small).

I'm not sure about the usability impact of this, while I can see that seeing the last-change within a directory is nifty, its a single field - but you may often need to see the last three or four changes made within /directory/. For that the changes view, or a changes review restricted to a single directory, are better UI approaches IMNSHO.