[MERGE/RFC] Dotted-decimal revision numbers in 'bzr log'

[Matthew D. Fuller]

This whole mail is IMAO, of course.  And as the person who's not doing
the work, I'm entitled to whine my fool head off and have no impact
whatsoever on what choices are ultimately taken.  But since I like
hearing myself type...


On Thu, Sep 28, 2006 at 04:45:21PM +1000 I heard the voice of
Robert Collins, and lo! it spake thus:
> 
> And we can assign branches from the merge point:
>  counting from the merge point:
> B:2
>   D: 2.1.1
>   E: 2.1.2

I dislike those, because now [part of] the revision number goes from
"earlier" to "later", and part goes from "later" to "earlier".


>  counting to the merge
> B:2
>   D: 2.1.2
>   E: 2.1.1

This would be my choice.  While it's unnaturally mathematically (x.y
is something past x, not before x), it feels natural expressively (x.y
is a subpart of x).  You can know that any bits of the merge that
created x are called x.y.  It's handy when you're paging through 'bzr
log | less' with big merges, because you can see just from a glance at
the revnos when you've skipped too far and are looking at another
[mainline] revision.  It means that merged revs "next" to each other
will have neighboring revnos.  etc.


> or from the branch point:
> B:2
>   D: 1.1.2
>   E: 1.1.1

This is somewhat interesting, but I don't like it so much in practice.
For one thing, AIUI, this means that a merge of a long-lived branch
will have merge revs with big skips in the revnos (i.e., branch, hack
10 revs, merge the last 20 revs of mainline, hack another 10 revs,
merge 15 revs of mainline, hack 5 revs, merge back into mainline).
That'll look confusing at a glance.  The main UI advantage of this is
that it gives you a visual cue to mentally construct a sketch of how
the ancestries came together, but I think that's mostly irrelevant for
simple situations, and just too hard to do offhand mentally for
complex ones; the various GUIish tools that draw graphs are much more
useful for mentally picturing that sort of history, I think.


> merges of a revision into another branch will not change its number
> if   [... qualifications ...]

I think this is a negligable advantage.  revnos are such a local
convenience item , that encouraging people to be able to think of them
as a globally-useful identifier in specific cases can only lead to
pain.



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