[BUG] apply_changeset / generate_changeset use wrong base

[John A Meinel]

Aaron Bentley wrote:
> John A Meinel wrote:
> 
>>>Yes, this I know of this limitation in the current implementation. There
>>>is even a comment in "apply_changeset" which states this.
> 
> 
> Okay.  I had seen that, but clearly got the wrong idea from our last
> conversation about this, because I wasn't sure how you wanted to fix it.
> 
> 
>>>I think the trick would just be to call:
>>>
>>>base = common_ancestor(cset_info.target, branch.last_patch())
> 
> 
> Okay, I can do that.
> 
> Aaron

Yeah, our last conversation wasn't very clear.

If you prefer, we could use "common_ancestor" or something similar at 
the time of changeset creation (meaning you could supply an explicit 
base). And this could be stored in the changeset as the "merge base".
I was prefer to call common_ancestor at the time of application, because 
there might have been merges, etc, since the time the changeset was 
created, which might change the best base was.

We could also have something like:

bzr apply-changeset --rebase

Which would use common_ancestor, otherwise it would use the "merge base" 
found in the changeset (defaulting to just the "base").

I'm open to suggestion. I just know that common_ancestor at the time of 
application is probably the easiest to implement and gets 95% of it right.

John
=:->

PS> Part of the problem was that I wrote the changeset code before 
common_ancestor got fixed. I know it is currently using 
"_find_best_base" which was a reimplementation of common_ancestor, meant 
to handle the branching ancestry, at a time when common_ancestor did 
not. So there are a few places like that which need to be cleaned up.

-------------- 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/20050927/0545cc71/attachment.pgp