merges and the dag

[Robert Collins]

so theres a DAG formed as merges occur:

revision-X incorporates the contents of merged revisions Foo, Bar...

One interesting this reviewing this DAG, for visualation, querying for
missing patches, development styles etc. 

One way to ensure its captured is to have each log list the other logs
its incorporating.

Lets say that Bar is the ancestor of Foo., and that Bar and Foo are
merged into my new commit Baz.

We could list all of the new entries:
i.e. <new-patch id="Foo"/><new-patch id="Bar"/>.

I think its more useful though to store only the new log heads :
<new-patch id="Foo"/>. The problem though, is that when cherry picking
occurs, Bar may not be merged at all. So we should list all the patches
anyway.
perhaps:
<new_patch id="Foo">
<new_patch id="Bar"/>
</new_patch>

Alternatively:
<new_patch id="Foo"/>
<new_patch id="Bar"/>
<new_merge id="Foo"/>

This means that introspecting the logs and walking out will take along
the actual paths take to merge into this tree, rather than having to
read in all the indirect merges and then perform set subtraction to
calculate the log heads after the fact. In writing various routines for
baz, I've found that its the log heads merged in that is usually needed.

Secondly, the merged-patches cache could be more useful if it also
represented this division between merged heads and their included
patches. I'm not sure how best to do this though.

Thoughts?


Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20050412/20fbf88e/attachment.pgp