Caching 'dotted_revnos' and merge_sort

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andrew Bennetts wrote:
> 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.
> 
> 

At one point I had a 'short' syntax that did the first chars and last
chars of a revid. So you could do "john-abcdef" sort of thing.

The big issue is that unless we *store* the revisions using such syntax,
they are not cheap to look up. sha hash prefixes work because the keys
are stored in sha prefix sort order.

Absolutely we could get rid of dotted revnos. We don't have any other
handle to non-mailine revisions that aren't the revision_id. I like that
we can present the user something they can approach with a sane handle.
Something I can remember without having to resort to copy and paste.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAku9N4kACgkQJdeBCYSNAANImwCgiJZE61dP8Djecfv2Z1VWy8QH
qmMAoIfD7Rwb76hTW/uCksgedzVk8zWA
=WK9I
-----END PGP SIGNATURE-----