Optimal Merge Base selection

[John A Meinel]

Martin Pool wrote:
> On 10 Jul 2005, John A Meinel <john at arbash-meinel.com> wrote:
...

> % weave annotate test.weave 4
>     0 | aaa
>       | bbb
>     1 | stuff from martin
>     3 | fix up merge
>     4 | modify john's code
>     0 | ccc
>     1 | ddd
>     4 | add stuff here
...
> John's revision 2 is known to be completely merged into 4, and doesn't
> generate any conflicts.  (Obviously in a real system we would use
> universal ids not simple integers.)  John now makes a new revision 5
> based on his last one, 2:
>
> % weave add test.weave 2
> aaa
> bbb
> stuff from john
> more john stuff
> john replaced ccc line
> added version 5
> % weave annotate test.weave 5
>     0 | aaa
>       | bbb
>     2 | stuff from john
>       | more john stuff
>     5 | john replaced ccc line
> % weave merge test.weave 4 5
> aaa
> bbb
> <<<<<<<< version 4
> stuff from martin
> fix up merge
> modify john's code
> ccc
> ddd
> add stuff here
> ========
> stuff from john
> more john stuff
> john replaced ccc line
>
>>>>>>>>>version 5

I thought the goal of the weave was to notice that the lines from 2 had
been superseded, and the only line which conflicts is the "john replaced
ccc line".

I realize the "4 doesn't conflict with 2" is nice, but doesn't it
translate higher up as well?

Maybe I'm expecting too much.

John
=:->

>
>
>
> The main problem with this is that the weave file for the inventory will
> get rather large if it's updated for every revision; thus the idea of
> either storing the weave in a smarter format or building it in memory
> when we merge.
>

Is this using the python Pickle method of storage, or something else?
John
=:->
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20050712/b1c91b23/attachment.pgp