display of merged revisions in loggerhead and log

[John Arbash Meinel]

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

Michael Hudson wrote:
> 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?

Basically that. You also run into issues with criss-cross merges and
other graph oddities. So that by the time you think you've finished, one
more branch just sticks out from the side and confuses things.

The other problem is that most of these start growing into the 100s of
revisions, and then trying to manually sort it out to figure out where
you might be going wrong gets difficult.

Other problems generally involve shortcut revisions and multiple start
nodes. (We have merged in several plugins and we have an 'A' revision
that shortcuts to NULL.)

Probably it would be nice to have a way to visualize how the graph
walkers step, and how they decide what is going on.

I had done some stuff with graphviz and numbering the graph, and colors,
etc. But I didn't want to spend too much time trying to generate a
visualization tool just to optimize the algorithm.

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

iD8DBQFH0HhtJdeBCYSNAAMRAmCEAKClpAZqmf3sQzw9B91pGd/tUSXOugCgs2ZK
KBGAMz5sO4dkabKOeQcddFk=
=mKSr
-----END PGP SIGNATURE-----