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

[Robert Collins]

On Wed, 2006-09-06 at 22:43 -0400, Aaron Bentley wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Robert Collins wrote:
> > Hi,
> >     This patch adds dotted decimal revision numbers to the output of
> > merge_sorted. I haven't profiled it carefully, but it should be
> > low-overhead. I've kept compatability, but we might want to just make it
> > always do this and deprecate getting output without the revision
> > numbers.
> > 
> > The revision numbers are assigned like CVS:
> > 
> > For a revision with number X, each child of X gets a revision number of
> > X.SEQUENCE.1. IFF SEQUENCE is 0, then the childs revision number becomes
> > X[:-1] + (X[-1] + 1) instead, which is what gives us the mainline.
> 
> Sorry if I'm being thick, but this explanation doesn't make anything
> clear to me.  How is SEQUENCE calculated?  Is X an integer?  If so, what
> does X[:-1] mean?  Are these values stable as new children of X are
> discovered?

Possibly easiest to describe is the new test sample data:

# in this test we setup a number of branches that all derive from 
# the first revision, and then merge them one at a time, which 
# should give the revisions as they merge numbers still deriving from
# the revision were based on.
# merge 3: J: ['G', 'I']
# branch 3:
#  I: ['H']
#  H: ['A']
# merge 2: G: ['D', 'F']
# branch 2:
#  F: ['E']
#  E: ['A']
# merge 1: D: ['A', 'C']
# branch 1:
#  C: ['B']
#  B: ['A']
# root: A: []
self.assertSortAndIterate(
    {'J': ['G', 'I'],
     'I': ['H',],
     'H': ['A'],
     'G': ['D', 'F'],
     'F': ['E'],
     'E': ['A'],
     'D': ['A', 'C'],
     'C': ['B'],
     'B': ['A'],
     'A': [],
     }.items(),
    'J',
    [(0, 'J', 0, (4,), False),
     (1, 'I', 1, (1,3,2), False),
     (2, 'H', 1, (1,3,1), True),
     (3, 'G', 0, (3,), False),
     (4, 'F', 1, (1,2,2), False),
     (5, 'E', 1, (1,2,1), True),
     (6, 'D', 0, (2,), False),
     (7, 'C', 1, (1,1,2), False),
     (8, 'B', 1, (1,1,1), True),
     (9, 'A', 0, (1,), True),
     ],
    True
    )

A was assigned revision number 1 because it was the first descendant of
the origin found.

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.

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 ;).

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.

Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060907/5d5919d5/attachment.pgp