When viewing the log of a mainline revision (i.e. simple revno), only mainline ancestors (i.e. the "history") are displayed. However, if the starting revision is from a merged branch (i.e. dootted revno or a corresponding revid), then the whole ancestry gets displayed, i.e. revisions from possibly many parallel branches. Both trac and human readers have problems with this, in particular as ordering of these revisions is somewhat arbitrary.
What trac can do, and can do really well, is a linear history. Every branch has a linear history. The current mainline does, these are the simple revision numbers. But every branch merged into mainline does as well. There should be a simple linear mainline path for every revision back to the initial null: revision. I guess it can be obtained by always following the first parent. This would yield dotted revisions from the same branch that contained the starting revision, but not from branches merged into that one.
The other direction is a bit less clear, but I guess that one can look for the earliest mainline revision having the revision in question as an ancestor, and always taking the correct turns in this fashion. Not sure we need a forward history of non-mainline revisions, though.
So I propose to re-implement the history generation to create a simple linear revision as described above.
bzrlib.