merges and the dag

[Robert Collins]

On Tue, 2005-04-12 at 17:30 +1000, Robert Collins wrote:

Following up..

> 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"/>

I think that what is most useful is to ensure each log includes:
* new patchs included via full-merges
* new full-merges
* new cherry pick log heads
* new patches included by a cherry pick

Which lets use do set algebra with just the log information, and
identify cherry picks vs full merges completely without scanning
outwards in the logs to determine which of the 'new patches included' is
a merge component or a cherry pick component.

I.e. if we have the following patch graph:
1-2-3-4
 \-5-6

and we merge in 6 and cherry pick 3 and 4 at the same time (rejecting
patch-2), the log should contain
<new_patch id=1/>
<new_patch id=5/>
<new_patch id=6/>
<new_merge id=6/>
<new_cherrypick id=4/>
<new_cherrypick_patch id=3/>
<new_cherrypick_patch id=4/>

This is orthogonal to what a cache might contain - though obviously a
cache would want to expose this usefully.

What do you think?

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/20050414/99a49d02/attachment.pgp