[RFC] Changing dotted revno numbering (was Re: Echoing a post: bzr vs. git)

[Matthew D. Fuller]

On Thu, Nov 06, 2008 at 10:36:36AM +0100 I heard the voice of
Vincent Ladeuil, and lo! it spake thus:
> 
> Glad to hear that since this is an idea I'm thinking about[1] :)

So, here are a few of the reasons I like it offhand.

- Less history walking.  To get the numbers, we only need to know the
  number of the merge rev (which we're seeing anyway most of the
  time), and the number of revs that are shown there (which needs
  walking some history anyway, to be sure).

- Better "feel", in the mode of thinking that thinks of those as
  "sub-revisions" of the mainline rev.  This is often a useful mental
  model, fitting with the idea of mainline revs as 'rollups'.

- It's not more or less "valid" in the sense of "where the revs fit
  into the graph" than the current schema; it's just a different sort
  of validity.  But I believe it's a more useful one.

  o One reason is the one mentioned earlier in the thread; having
    299.1.7 coming "after" 300 in the history just sounds weird.

  o Another is that it makes it easier to flip through long logs.  If
    there are 50 revs in a given merge, that's a lot of bouncing on
    the space bar in less, and it's easy to miss the beginning of the
    next mainline rev.  If the numbers of the merge revs showed which
    mainline rev we were "inside", it would be much more obvious how
    far we had left to go.

    * Also helping this case is that we know from the first merge rev
      shown about how many there are that we'll have to flip through,
      and we know that the last one will be ".1".  Better idea of how
      much farther we have to go.

- Can be more predictable.


> One fear I have is that changing the numbering may encounter
> resistance from users, so since you raised the subject,

An excellent reason; POLA always argues against it.  Which is one
reason I haven't brought it up since I failed to win the discussion
pre-0.12   :)


> The actual numbering has one fundamental property we must keep: it's
> stable in the branch context (except when ghosts are involved, but
> little can be done against that, when ghosts incarnate, some things
> have to change anyway :)

Which this would fill, at least as well as most other solutions; once
the mainline rev is created, no new revs will appear under it.  Ghost
fills in that list of merge revs would change things.  Ghost fills
back in the branch mainline would too, through affecting the revno of
the merge rev itself.  Neither of these seems more likely or hazardous
than the current setup, though.


> We can also reverse BRANCHREVNO as: BRANCHREVNO starts at one for
> the last revision created before merging and get incremented by 1.

I would go the other way, I think.  That way every component of the
number counts downward toward the "past".  The lowest numbered
MAINREVNO is the farthest back, the lowest numbered BRANCHREVNO is
the farthest back, and the lowest numbered BRANCHREVNO is the farthest
back.

(substitute "farthest forward" if you're --forward'ing of course)



-- 
Matthew Fuller     (MF4839)   |  fullermd at over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
           On the Internet, nobody can hear you scream.