Dotted revno "algebra"

[Vincent Ladeuil]

>>>>> Eric Siegerman <lists08-bzr at davor.org> writes:

<snip/>

    > By the same token, others have proposed numbering dotted
    > revisions based on their merge point, rather than their branch
    > point.  I find that idea to be rather horrifying.  Under such a
    > scheme, IIUC, rev. 47.1.1 would be an *ancestor* of rev 47, not a
    > descendant.

Well, version numbers for released softwares do some funny stuff too
here: 1.0 comes before 2.0 but 2.0beta comes before 2.0 no ? So we are
all using some heuristics that are not usual arithmetic ones here :)

Moreover, the middle part in the dotted revno is... nearly opaque if you
can't visualize the merge subgraph, so it's not helpful to understand
this subgraph ordering.

<snip/>

    > Numbering dotted revnos by merge point would greatly reduce the
    > (valuable) partial-ordering property,

It will define a different partial ordering, yes, but, AIUI, will still
suffer from the same problem for the middle part.

    > and IMO would make revnos much more confusing.

But will answer the question I most often ask when dealing with revnos:
*when* was this merged in my mainline (as opposed to when was it branched
from my mainline which I'm rarely, if ever, interested in, expect maybe
at conflict resolution time, but even there...) ?

Regarding the final part in the revno, both numberings (from merge point
or branch point (not exactly that but good enough)) have pros and cons,
there is still room for discussion.

I'd like to understand what you are using the revno branch point for
(except for the ordering that is) ?

       Vincent