Caching of expensive computations

Several computations that trac expects to be cheap are quite expensive in bzr. This problem could be mitigated by introducing caches. There probably should be one per-repository cache mapping revision ids to parents, gdfo (greatest distance from origin), length of lefthand history (i.e. revision number this had in the branch it was originally committed to). Then there should be per-branch cache, associating revision ids, dotted revision numbers, merge points and suitably defined next revisions. And finally there should be some cache from which a svn-style last modification for each directory can be obtained in O(log gdfo), because caching the last modified revid for every possible combination of fileid and revid would probably be too expensive.