Caching 'dotted_revnos' and merge_sort

[Andrew Bennetts]

John Arbash Meinel wrote:
> I've been toying around with some ideas about how to make history
> management a bit better in bzr. Specifically focusing on dotted_revnos
> and some other aspects that are currently 'whole ancestry' operations.

This is pretty interesting.  But I wonder if perhaps we should take a
totally different approach: remove dotted revnos entirely, or at least
redefine them (again!) to be something utterly cheap to calculate — even
if it means losing properties like “each revision-id in an ancestry has
exactly one dotted revno in that ancestry” and “always gives a
relatively short string”.

Basically I'm wondering if the benefits of dotted revnos justify the
costs (both in existing runtime, and in developer effort to optimise
that runtime)?

I personally use them very rarely, and wouldn't really miss them much if
they were replaced with something cheaper.  I don't find the numbers
give much help at all in understanding the history of a branch, I always
need a graphical tool for that (knowing where a revision was branched
from is almost always less interesting to me than knowing where it was
merged into).

As a strawman suggestion, what about a syntax to refer to part of the
unique revid, e.g. suffix:f00f (for matching revid with suffix of
..f00f).  Or some other scheme that is cheap to calculate and feasible
to copy and paste.

-Andrew.