Determining latest branch revno takes exceptionally long
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Trac-Bzr |
Fix Released
|
Low
|
Martin von Gagern |
Bug Description
When browsing the content of an unversioned directory which contains branches, trac-bzr will generate a BzrDirNode for each of its entries. Each node will in turn fill its whole revcache to determine its revision number. If one has a directory containing multiple branchs of a large project, this will take way too long.
The returned revision number is a dotted revision number, where I would have expected the revno of the latest mainline commit, even if that was a merge without modifications. After all, trac-bzrogs of branches only list mainline (left-hand side) revisions unless the starting revision is not on the mainline. Therefore the directory listing should only use mainline versions, too, unless the version for which the listing is requested was dotted.
Both the number formatting and the performance problem can be easily solved by special-casing the case of a branch root, avoiding or delaying the revcache generation for these. I plan to write a fix soon.
Related branches
- Trac-bzr-team: Pending requested
-
Diff: 106 lines (+67/-11)1 file modifiedtracbzr/backend.py (+67/-11)
Changed in trac-bzr: | |
assignee: | nobody → Martin von Gagern (gagern) |
importance: | Undecided → Low |
Changed in trac-bzr: | |
status: | New → In Progress |
tags: | added: performance |
Changed in trac-bzr: | |
milestone: | none → 0.3.0 |
Changed in trac-bzr: | |
status: | In Progress → Fix Committed |
Changed in trac-bzr: | |
status: | Fix Committed → Fix Released |