Bug in reweave

[John A Meinel]

Aaron Bentley wrote:
> For those reading this, this bug cannot affect new, natively-created bzr
> branches.  It's strictly related to upgrades and conversions from other
> formats, with ghosts present.
> 
> John A Meinel wrote:
> | Attached is a diff of the specific content which disagrees. (it is in
> | the inventory)
> 
> Thanks for your quick work on this, John.  I was afraid something like
> this could happen, but I was worried about baz2bzr imports disagreeing.
> ~ Same case though--ghosts.

Yeah. Any time where we might determine that texts were actually changed
by a different version.

Also remember, though, that for a while we thought the correct
'revision' was the merge point, versus when we recognized that it
happened on one tree rather than the merge point.

> | <message>- merge in separately-developed weave code</message>
> 
> Oh, the irony!

Yeah. It was one of the very first merge points.

> 
> | I think what happened is that in the upgrade code, in one branch it
> | actually had the revision, and could attribute the text to the correct
> | revision, in the other branch, it had to guess, so it guessed *this*
> | revision. Now they disagree, so now they can't be merged.
> 
> Well, I don't have any brilliant ideas.  I am rather surprised that the
> parent revisions are incorrectly noted in the revision, though.
> 
> Aaron

Well, the reason we are running into it now, is because we are doing
Weave.join() rather than just tacking on new revisions on the end. Which
means we are actually revisiting older entries and noticing that we
disagree.
The positive side of this is that we are less likely to have the problem
in the future, because there are more opportunities for comparisons to
occur.

The easiest thing to do, is to just declare one of them the "official"
version, and then rsync/manually wget the file and replace the
conflicted one.
Since you are pulling his tree, it makes sense which one should be used.

Also, I can see that bzr.dev seems to have the 2-ancestor version as well.

And since 37f38 only exists in the revision declaration (meaning it has
no last-changed texts associated with it) again I think it is accurate.

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060126/9da7bcba/attachment.pgp