[MERGE/RFC] Add dotted-decimal revision numbers to merge_sorted output

[Aaron Bentley]

Robert Collins wrote:
> Then we have the allocation of revision numbers to 4 descendants of A:
> B, D, E, H.
> D is the first found during the search and gets allocated sequence
> number 0
> B is second - gets 1
> E is third and H is forth, getting 2 and 3 each.

What order does the search go in?

> So D gets 1.0.1 (1 from A, 0 from A's sequence when D is first examined,
> the rightmost 1 is a constant). This is transformed into '2' by the
> special case for the first descendant.
> 
> B gets 1.1.1 (1 from A, 1 from A's sequence number when B is first
> examined, the rightmost 1 is a constant)
> 
> E gets 1.2.1 (1 from A, 2 from A's sequence ... you get the idea I
> hope ;).

Much clearer.  I did some thinking about this for weavediff, which used
positional indicators instead of revision-ids for parents, but that case
was easier because the conditional indicators didn't need to resemble
revnos.  So they indicated distance from the target revision, rather
than distance from the origin.

> And yes, they are stable - as long as ghosts are not filled in. Doing a
> pull can change them because pull can give you a tip which
> short-circuits past revisions along its left-most parent compared to the
> graph before you pulled. But any number of merge and commits will not
> cause destabilisation.

I don't see how that's possible.  If I merge Z, that may fetch Q, and Q
may be descendant of A, and the new sequence might be B, Q, D, E, H
which would mean that D, E and H would be renumbered.  It isn't just
pulls and filling in ghosts that can destabilize it, AFAICT.  It's any
kind of fetch.

Aaron