Revenge of the pretty pictures

Thu Sep 22 21:58:57 BST 2005

Aaron Bentley wrote:
> John Arbash Meinel wrote:
> 
>>>You don't really need the dXXXX for revisions in the main branch, as
>>>they are always the same distance as their revno.
> 
> 
> Actually, that's not so.  d represents the max-distance-from-root.  That
> means that if a revision merges a revision whose max-distance-from-root
> is >= its revno, the distance will be greater than the revno.
> 
> For an example, look at the graph for the bzr.dev mainline.
> Revision 1193 has a distance of 1196, because one of its parents is
> 8e4ad, whose distance is 1195.

Okay. I'm not sure if knowing the explicit distance is worthwhile or
not. But it probably is for your uses (since it helps you understand
merging).

> 
> 
>>>It would be nicer to have some other information to put there, but since
>>>there isn't much that is small enough and worthy enough. Perhaps the
>>>date of commit 2005-05-05 is pretty small, and might mean something.
> 
> 
> True.  I'll put that in.

I'm actually playing around with using the "href" attribute, and
generating custom cmap files. It lets you create a .png file and then
some html which uses the cmap, and lets you have nice mouseover
information as well as a link to something else.

The only problem I see right now, is that the "title" defaults to the
label of the node. While I would like to sneak in extra information.
Also, I don't see any way to make the "title" be more than one line
('\n' is printed literally).

But for the steps to reproduce my work, apply this patch (dot will only
create an entry in the cmap if you have a href associated with it):
=== modified file 'dotgraph.py'

--- dotgraph.py
+++ dotgraph.py
@@ -44,6 +44,8 @@
         if label is not None:
             attributes.append('label="%s"' % label)
         attributes.append('shape="box"')
+        if self.rev_id is not None:
+            attributes.append('href="%s"' % self.rev_id)
         if len(attributes) > 0:
             return '%s[%s]' % (self.name, " ".join(attributes))

Then run these commands:

bzr graph-ancestry . ../test.dot
cd ..
# This should actually do the layout, just
# to make sure the next steps are consistent
dot -o test-layout.dot test.dot
dot -Tpng -o test.png test-layout.dot
dot -Tcmapx -o test.cmap test-layout.dot
echo "<html><head></head><body>" > test.html
echo '<img src="test.png" usemap="#G" />' >> test.html
cat test.cmap >> test.html
echo '</body></html>' >> test.html

What I'm thinking is that we might be able to have the graph-ancestry
command generate the cmap, so you could do:
bzr graph-ancestry --html=../test.hmtl . ../test.png

Which would generate a complete webpage, along with an annotated cmap,
with extra information. I know you mentioned doing it with svg, but svg
isn't completely supported yet.

I think there is some promise with the cmap. At the very least, we could
make the "title" parameter be the first line of the commit message. Or
we could make it something like "bzr log --short".


> 
> 
>>>Also, I think I like the clustered form more than the non-clustered. As
>>>I think it makes the ancestry follow a nice line
> 
> 
> Most of the time, it does.  Where it falls down is when you do a merge
> base, and the line goes from one cluster to another.  The other thing is
> that it allows parents to be lower on the graph than their children,
> which looks strange.
> 
> 
>>>And finally, it would be nice to have a color code (possibly in --help),
>>>so that we can figure out what --merge-branch means.
> 
> 
> A legend?  I do have one in help, but it's descriptive:
> 
> If --merge-branch is specified, revisions in the merge-branch are red,
> revision in the common history are orange, revision that are common
> ancestors are blue, and the merge base is green.

Okay, I see that now. I just didn't read it thoroughly enough.

> 
> Maybe I should adopt your style; you got the colours right, except that
> 'white' is really just 'no-colour', and doesn't mean OTHER merges.

Well, the revisions exist from somewhere, right? So it means that it is
ancestors of the OTHER tree, since they aren't common, and they aren't THIS.

I'm also wondering about a definition of THIS versus COMMON. Because if
the OTHER tree has merged THIS in the past, those are actually common
revisions.

Maybe it makes more sense the way you do it, but on first glance, I feel
like the red entries are the ones that need to be pulled in if a merge
is done. But really it is the red entries that are children of the green
one, right?

John
=:->

> 
> Aaron
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20050922/c430fac4/attachment.pgp 
