Dotted revno "algebra"

[Vincent Ladeuil]

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

    > On Tue, 2010-05-04 at 14:19 +0200, Vincent Ladeuil wrote:
    >> 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 :)

    > That only works because the "beta" signals that it and the
    > following stuff are out of band.  Have you ever seen a project
    > that numbers prereleases leading up to 2.4 as simply 2.4.N?  I
    > sure haven't!

No of course.

    > That said, let me retract the bit about dotted-decimal being a
    > "straightforward extension of (single-)decimal arithmetic".  It
    > isn't, as revno (or release) 2.1.10 follows 2.1.9, whereas
    > in math, (2.10 < 2.9).

My point was more along these liens.

    > A more precise statement of the property I value is that "X.Y" is
    > equivalent to "X.Y.0".

You're still handwawing a bit here since there is no good ordering for
Y.

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

    > True.  I don't rely on the interior components nearly as much as
    > on the first and last ones.  To me, they're only there to
    > disambiguate multiple branches that sprang from the same rev.

In complex scenarios they more than that as the merged subgraph could
itself contain multiple merges and in this case they refer to inner
branches and frankly I'm quickly unable to predict them in these cases.

    >> 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...) ?
    >> 
    >> I'd like to understand what you are using the revno branch point
    >> for (except for the ordering that is) ?

    > I don't need the revno to tell me where the merge point is; "bzr
    > log -n0" *shows* me that.

Hmm, except when that outputs MB of data and the merged point is pages
(10ths) from the revno itself.

    > But "log" doesn't indicate where the branch point was; I determine
    > that by comparing revnos.  (Not sure why I care about the branch
    > point more than you seem to do, but, well, I do care about it.)

That was my question, why do you care about it. Really, I'm sure there
are valid reasons and I'd like to understand them.

    > And qlog is a great visualization tool, but there's that
    > keyboard/mouse context switch again.  With branch-point numbering,
    > I can use log to understand a typical feature branch; I only need
    > to resort to qlog for more complex situations.

Yeah, so, already you acknowledge that log falls short to help for
complex graphs. :-(

    >> > Numbering dotted revnos by merge point would greatly reduce the
    >> > (valuable) partial-ordering property,
    >> 
    >> It will define a different partial ordering, yes [...]

    > Yeah, in which "X.Y" won't mean "X.Y.0", but more like
    > "X.Y.infinity".  *Shudder*

The debate is still opened about whether Z (in.X.Y.Z) should start at 1
or not.

As it also is about finding a good solution for Y...

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

    > Apparently...  But at least we can now discuss it purely on the
    > basis of (competing ideas of) usability, since, as you point out
    > in another post, John's recent work has essentially factored out
    > the performance issues.

Yup, that's the key IMHO, whether we should *replace* it or leave it as
an option could be investigated *once* we have addressed the grah
loading in a efficient way.

     Vincent