[RFC] X.Y.Z dotted revnos
warthog618 at gmail.com
Thu Jan 10 23:35:18 GMT 2008
-----BEGIN PGP SIGNED MESSAGE-----
John Arbash Meinel wrote:
> 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
>> 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 ,-------------'
The one shown here is option "D" from your previous mail.
And how come O is 1.5.3, not 1.4.3?
> 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
> 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
> 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.
Just to clarify - this is a forced merge, with X representing
uncommited changes that C is being merged into, right? If so your new
numbering makes more sense than the old.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the bazaar