[RFC] X.Y.Z dotted revnos
John Arbash Meinel
john at arbash-meinel.com
Thu Jan 10 21:43:21 GMT 2008
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
=:->
More information about the bazaar
mailing list