brisbane: initial cut at a mergeline cache

[Jonathan Lange]

On Wed, Apr 1, 2009 at 2:21 PM, Andrew Bennetts
<andrew.bennetts at canonical.com> wrote:
> 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. I'm strongly against this - the current scheme
>> makes the most conceptual sense IMNSHO. We *can* make the current scheme
>> perform well - it just needs a small cache giving fast lookups for
>> revisions in recently added merges.
>
> Actually, I don't find the current scheme particularly helpful in my
> day-to-day use.  When I'm examining history I'm much more interested in when
> something landed than when something was branched.  So when annotate or log
> tells me something happened in 100.2.3 I get a bit frustrated because at
> that point the revno could be telling me which mainline revision that change
> landed in, but instead it's telling me something else that doesn't help me.
>
> The other thing I do with dotted revnos is treat them as opaque handles to
> feed to e.g. "bzr diff -c".  For that purpose it doesn't matter how they are
> assigned (so long as they are unambiguous, of course).
>
> So I at least probably wouldn't mind if the dotted revno scheme changed
> (although the flux in user experience would be extremely unfortunate, so from
> that perspective I would be reluctant).

I agree entirely with Andrew.

I also wouldn't mind if the dotted revno scheme were abandoned
completely. Any short unique identifier would suit for my purposes.

jml