display of merged revisions in loggerhead and log

[John Arbash Meinel]

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

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.

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.

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

iD8DBQFHz7EnJdeBCYSNAAMRAk9YAKCGmlzg4xww2EOsYJBKFQSPaddEdgCZAbgB
bcjRDacYPLzNnWchnFp/qa8=
=G4ky
-----END PGP SIGNATURE-----