Determining latest branch revno takes exceptionally long

Bug #487704 reported by Martin von Gagern
6
This bug affects 1 person
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.

Tags: performance

Related branches

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
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.