brisbane: initial cut at a mergeline cache

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


...

> 
> I very much agree that making changes from a "proper" to a less so
> thing just because we can't (or haven't) made it perform well is a
> step in the wrong direction.
> 
> Still, my reasons were UI based from the get-go.  Here's another one:
> if you think of those non-mainline revisions as being "sub-revs", as
> the UI tends to present them, having them numbered as if they were
> "parts" of the mainline rev they came in as makes perfect sense.
> 
> 
> Numbering from the merge point may convey "less" information about the
> rev, but I just don't think it's information that you [generic]
> usefully gather by mind from that number.  A UI like log or
> graph-ancestroy or a graphical viewer is a lot better for
> investigating and picturing the ancestral twisting and twining.  The
> information merge-point numbering gives, IMO, is information that much
> more useful in the times where the dotted revno is more than an opaque
> string.
> 

So there is also a question about how to display revisions that haven't
quite-yet been merged into your branch. If you number from source, then
they get labeled as though they were merged, and probably end up with
the same numbers.

If you number from merge point, then they almost definitely would have
changed by then.

I think the main argument for numbering from source is because if we
both merge "foo" then all the revnos for foo are likely to be the same
between branches. (They are not guaranteed stable, as you may have
merged something else descended from the same revision, and I have not,
but they are "more" stable.)

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknTftcACgkQJdeBCYSNAANmQgCgi1C5RuMZWU8nGhz926B58wTK
QLYAoLuUUmGdueTvBGdfapOD7D8JmoI/
=yqYp
-----END PGP SIGNATURE-----