Dotted revno "algebra"

[Martin Pool]

I think that users see the dotted revnos basically as near-opaque
tokens for revisions.  They're not inherently useful or meaningful to
anywhere near the degree that mainline revnos are.  (Even there,
opinions vary and there are caveats on how you can use them, but the
ordering relationship is basically useful.)

If all we need is a handle for a revision, it seems unattractive to me
to define this in a way that depends on the graph size - even if it's
a relatively cheap algorithm or it's not the entire graph or it's
sometimes satisfied from cache.  To me much of this discussion feels
like microoptimization of something that we know is not a global
maxima.

Now in your case 4, we're starting to talk about when the user
specifically wants to point to a path through the graph, and I can
definitely see that being useful in some simple cases like "the
revision merged in by r20" or "the 3rd ancestor of the 2nd parent of
r20".  (Which is a bit like git's operator grammar for revisions.)
Perhaps these cases would be the most common ones for wanting to refer
to non-mainline revisions from the command line, other than pointing
to them.  You could also want to say "the commit that was r20 on the
branch nick abcd", though obviously that's not guaranteed to be
unique.

> 4) I wonder if we would be better off choosing a more obvious grammar.
> For example, imagine if a number indicated to more N parents back, and .
> symbol indicated to move to a right-hand parent. Then the question
> becomes whether we want to special case the first number, to count up
> from zero, or to count back from the tip. (is 1 the first commit, or is
> it last commit.)

These things are a bit more like searches than original names, in the
sense that they may not be guaranteed unique (indeed may be N:N) and
they're not necessarily cheap to calculate for all revisions when eg
printing a log.  In that case I think you would normally want
something that is extremely cheap to calculate just from the revision
id.  At which point I would probably come back to using the revision
object hash from the current format, which won't be stable across
revision representation changes, but will be stable across branches,
and istm that we could both print that and look it up quite cheaply.


-- 
Martin <http://launchpad.net/~mbp/>