display of merged revisions in loggerhead and log

[Michael Hudson]

John Arbash Meinel wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Michael Hudson wrote:
>> Note that I'm replying to a mail from several months ago here.
>>
>> The topic was how to make it apparent that the committer of a merge
>> revision didn't necessarily do all the work being merged.
>>
>> Martin Pool wrote:
>>> On 7/17/07, Michael Hudson <michael.hudson at canonical.com> wrote:
>>>> I don't really have a good answer to this.  Maybe you could list all
>>>> authors who committed to the branch being merged since it diverged from
>>>> mainline?
>>> You could try what gmail does, and show, on one line, the first name
>>> (or userid) of the people who contributed to a merge, truncated with
>>> elipsis if there are more than about four.  I'm not sure I'd like it
>>> but it would be interesting.
>> I actually got around to having a hack at this this morning.  I've
>> attached two screenshots of my efforts.  The first does something like
>> what Martin suggests, though it doesn't restrict itself to first names.
>>  Perhaps it should, because the main problem with it is that it takes up
>> too much horizontal space.  This attempt is also extremely hacky, it
>> wouldn't be appropriate for branches which didn't work like bzr.dev.
>>
>> The second just adds a "Branch authors" field to the information that
>> drops down when you click the arrow next to a revision.  This seems like
>> a better bet, probably.
>>
>> Currently the code for this is using find_differences, which I've been
>> warned isn't necessarily accurate -- but it's certainly fast, which
>> doing things with get_ancestry() isn't.  Are the situations where it's
>> wrong likely to arise in practice for what I'm doing here (basically
>> "find_differences(revid, get_revision(revid).parent_ids[0])")?
>>
>> Cheers,
>> mwh
> 
> At the moment, it is just likely to return more nodes than are truly
> accurate. So *some* of the revisions that are considered unique to one
> side are actually common nodes.

I think I can see how this must at best be tricky: if you're computing 
the difference between revs A and B, both of which are near-ish the top 
of a large history and one of the ancestors of A has a parent which is 
waaay off in the deep history, you'll have to walk a long way back to 
find that this was actually an ancestor of B too.

Or is it more complicated than that?

> You need to be outside of a star topology to get that effect, and one
> could argue that it is just a small display issue.

For the use I'm putting it to, it's a little hard to care, yes.

> In trying to "fix" it, I wasn't able to make it correct without making
> performance drop significantly. I still have some patches for it, and
> with any luck I'll be able to get back to it in the future.

I do actually have a maths degree and did do a course on combinatorics 
so I've occasionally thought about sitting down and trying to really
prove things about the Bazaar graph requirements.  But that requires a 
great deal of brain time and I've never gotten around to it.  Also, 
getting good performance in Bazaar is likely as much about making 
intelligent guesses about the likely shapes of the graphs versus the 
questions that are likely to be asked rather than any theoretical limit. 
  But it still might be fun.  I also have to admit that I hated the 
course :)

Cheers,
mwh