[RFC] X.Y.Z dotted revnos

[John Arbash Meinel]

John Arbash Meinel wrote:
> Attached is a possible patch to our dotted revision number generator.
> It isn't suitable for merging, because I have to track down all of the
> tests that expected our old style numbers. For now, I'm going with
> option "C'" from my previous email. Specifically, the numbering looks like:
> 
>    A1
>     |\
>    B2 C1.1.1 -------.
>     | |      \       \
>    D3 E1.1.2  F1.2.1  M1.4.1
>     |/       /  |     |
>    G4 H1.2.2  I1.3.1  N1.4.2
>     |/       /        |
>    J5 K1.3.2          O1.5.3
>     |/               /
>    L6 ,-------------'
>     |/
>    P7

In cleaning up the tests, I have found one place where the non-nested
values differ.

		Old		New
 A		1		1
 |		|		|
 B-.		2-.		2-.
 |\ \		|\ \		|\ \
 | X C		| | 2.2.1	| | 2.1.1
 | |/		| |/		| |/
 | D		| 2.1.1		| 2.2.1
 |/		|/		|/
 E		3		3

This happens because the existing code assigns the numbers as it
traverses upwards, while the new code assigns them when it traverses
downwards.

I was originally hoping that the simple forms wouldn't change. And only
when you would usually have more than 3 digits would there be any
differences.

However, looking at the graph, I can at least argue the new form is
"more correct". Obviously C has to occur before D, because it is merged
into D. Thus having it get a lower branch number makes logical sense.
OTOH, D *is* closer to the mainline than C.

It isn't trivial to change my algorithm, because at the time you visit a
node, you usually have not evaluated its parents, and thus you don't
know what mainline node it corresponds to. The existing scheme doesn't
care, because assigning node numbers is a strictly local operation. It
uses orthogonality to insure uniqueness.

Anyway, I'll finish up the patch and send a merge request, but I figured
I would bring up this small point for discussion.

John
=:->