brisbane: initial cut at a mergeline cache

[Matthew D. Fuller]

On Wed, Apr 01, 2009 at 02:21:36PM +1100 I heard the voice of
Andrew Bennetts, and lo! it spake thus:
> Ian Clatworthy wrote:
> [...]
> > Another option suggested is to change the numbering scheme
> > altogether so that x and y are related to where the branch gets
> > merged into, not where the branch originated from.
> 
> Actually, I don't find the current scheme particularly helpful in my
> day-to-day use.

Ditto.  I've preferred merge-point-based numbering since we had the
dicussion when dotted revnos were being implemented.  While ancestral
numbering has some theoretical information-bearing capabilities, I've
never found any time it meant anything other than "Gee, now I know how
freakin' old Joe's branch was when he started working on this", and
that only when I had its landing rev in sight.

Actually, I find it interesting that you [Ian] feel so strongly that
way, in view of you just championing and making the change for log
--long to not show merge revs by default.  That's based on the POV
that considers "what happened on this branch" to be the most important
data to view most of the time, and numbering the revs based on when
they appeared in this branch actually fits far better with that than
numbering them based on when they departed.

It also has other advantages; picture reading through a long --long
(well, with -n0 now) on something like bzr.dev, where each mainline
rev is a merge of dozens or hundreds of revs.  With merge-point-based
numbering, you know about where you are in the history.  With
ancestral, you don't, and if you're flipping through it fast you can
even blow right past the next (previous) mainline rev without even
noticing it.


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