Caching of expensive computations

Registered by Martin von Gagern on 2009-12-16

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.

Blueprint information

Status:
Not started
Approver:
Martin von Gagern
Priority:
High
Drafter:
Martin von Gagern
Direction:
Approved
Assignee:
None
Definition:
Drafting
Series goal:
None
Implementation:
Unknown
Milestone target:
None

Related branches

Sprints

Whiteboard

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.

Subscribers

No subscribers.