Annotation oddness

[John Arbash Meinel]

Aaron Bentley wrote:
> Hi all,
> 
> bzr annotate / gannotate aren't doing what I'd expect.  When I annotate
> builtins.py, the text of the GPL is attributed to
> aaron.bentley at utoronto.ca-20050918214753-129f45a74b8af9f2 ("9f2"
> hereafter) even though it has been there since revno 1470, when
> builtins.py was created.  In fact, 9f2 did not affect builtins.py in any
> way.  It only altered revision.py and testmerge.py.
> 
> The inventory for 9f2 lists the revision-id for builtins.py as
> "aaron.bentley at utoronto.ca-20050913024207-489d573af4b76c4d".
> 
> Anyone understand why this is happening?
> 
> Aaron

If you look at the knit index, it has created a fulltext version of
builtins.py as of that revision. (At least on my machine)
vi .bzr/repository/knits/*/builtins.py*.kndx

And then if you look at the fulltext with:

zcat .bzr/repository/knits/*/builtins.py*.knit | vim -

Just search for af9f2...

Anyway, it attributes every line in the file to you at that point.

Going back to the knit index, it shows that there is no other parent for
that specific fulltext. I think it was a bug in our early implementation
of knit indexes.
Because if you look at it, the first entry has a range, but no parent
(makes sense).
Then next fulltext entry also has a range but no parent (your revision,
which is obviously incorrect).
Then we have another abentley revision, with no parent.
Then a john at arbash-meinel. fulltext with no parent
And finally, we get to a robertc@ revision which has a fulltext, but
properly has a parent entry.

If you look at 'john at arbash-meinel.com-20050918014804-c652edd3718c6498'
you will see that I also didn't touch 'builtins.py' in that revision.


This isn't the only file where it happens. Look at:
vi .bzr/repository/knits/*/branch.py*.kndx

And I see spurious fulltexts with no ancestors in there as well. With
the same revision ids.

I think there was a bug in bzr in the past. I don't know which one it
was. We had the merge bug where once a file was merged, all descendants
thought that you had 2 parents and would create a new entry.

I think this is probably solvable if we regenerate the knits by walking
revisions => inventories => knits.

By walking revisions we are guaranteed to get the correct parent
revision ids, and by walking inventories, we are guaranteed to get the
right files modified.

So we have a bug in our history right now. And it seems like both Aaron
and I committed a change with a bzr that exhibited this bug.

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060619/481127ef/attachment.pgp