Incorrect results from annotate on packs

Lukáš Lalinský lalinsky at gmail.com
Sat Dec 29 06:51:38 GMT 2007


On Dec 29, 2007 5:52 AM, Aaron Bentley <aaron at aaronbentley.com> wrote:
> Lukáš Lalinský wrote:
> > Hi,
> >
> > I was working on qannotate that won't freeze the GUI with packs and
> > decided to go the DIY route. When I was testing my implementation I've
> > noticed that I'm getting different results -- the test case was
> > bzrlib/builtins.py and surprisingly many revisions from 'bzr annotate'
> > that were marked as introduced by PQM. For example the first line ('#
> > Copyright (C) 2004, 2005, 2006, 2007 Canonical Ltd') using my algorithm
> > is:
> >
> > 2279.3.1 mbp at sourcefrog.net-20070213092108-i27nldyjijw0cqsq
> >
> > but 'bzr annotate' says it's:
> >
> > 3052 pqm at pqm.ubuntu.com-20071129180655-yv661adx0qb6a50z
>
> Well, one thing I can say is that revno 3052 is not
> 'pqm at pqm.ubuntu.com-20071129180655-yv661adx0qb6a50z', it's
> 'pqm at pqm.ubuntu.com-20071129184101-u9506rihe4zbzyyz'.
>
> 'pqm at pqm.ubuntu.com-20071129180655-yv661adx0qb6a50z' is revno 3051

Sorry, copy&paste error.

> As for why it's attributed to revno 3052, that version is a merge of
> 'lalinsky at gmail.com-20071128172710-eaf9o9y8vw2z5joa' and
> 'abentley at panoramicfeedback.com-20071127194032-f51sqjvldlwz7nc1'.
>
> These versions disagree about the origin of the line, so our rule is to
> assign it to the current revision, i.e. revno 3052.

I'm afraid I don't see this. According to bzr log,
'pqm at pqm.ubuntu.com-20071129184101-u9506rihe4zbzyyz' is a merge of
'pqm at pqm.ubuntu.com-20071129180655-yv661adx0qb6a50z' and
'abentley at panoramicfeedback.com-20071129173223-vxdci7trlqn5h083'.
'lalinsky at gmail.com-20071128172710-eaf9o9y8vw2z5joa' has only one
child revision, and it's a single-parent revision, not a merge. Same
for 'abentley at panoramicfeedback.com-20071127194032-f51sqjvldlwz7nc1',
except that in this case the revision itself is a merge. But as far as
I can see, neither of these revision touches the copyright line
against any of their parents.

> > Any ideas why it gives wrong results on packs?
>
> I'd say it's too early to say that the packs result is wrong.

I still think it's wrong. I can understand why results on knits might
be different or possibly wrong, but on packs it reannotates everything
with the same sequence matcher, without any historical bugs. And I
really don't see how PQM could be author of any line if it refuses a
clean merge (and the merge algorithm uses the same sequence matcher as
annotate), in which case the lines should be attributed to their real
authors, not PQM.

Lukas



More information about the bazaar mailing list