double-clicking on some line in "bzr gannotate" says "no such file", shows no diff

[Anne Mohsen]

I'm using bzr's and bzr-gtk's development branches.
I branched this https://code.launchpad.net/~bk-merge/mysql/mysql-6.0
then did "bzr gannotate sql/sql_tablespace.cc".
Scrolled down to these lines:
  else
  {
    my_error(ER_ILLEGAL_HA_CREATE_OPTION, MYF(0),
             ha_resolve_storage_engine_name(hton),
             "TABLESPACE or LOGFILE GROUP");
    DBUG_RETURN(HA_ADMIN_NOT_IMPLEMENTED);
  }
  write_bin_log(thd, FALSE, thd->query, thd->query_length);
  DBUG_RETURN(FALSE);
}
and double-clicked on the "my_error" line above. I got:
Traceback (most recent call last):
  File "/home/guilhem/.bazaar/plugins/gtk/annotate/gannotate.py", line 261, in line_diff
    window.set_file(tree1.id2path(self.file_id))
  File "/home/guilhem/.bazaar/plugins/gtk/diff.py", line 467, in set_file
    self.diff.set_file(file_path)
  File "/home/guilhem/.bazaar/plugins/gtk/diff.py", line 392, in set_file
    raise NoSuchFile(file_path)
bzrlib.errors.NoSuchFile: No such file: 'sql/sql_tablespace.cc'
and no diff window.
That is weird. The file has existed, without interruption if I look at its history, since January 2006.

[Daniel Fischer (dannythefool)]

Copying from an e-mail about this problem that I wrote:

It appears to be a bzr gannotate / bzr annotate bug. The revision that annotate shows for the location mentioned in the bug report is an empty merge changeset. The actual change did not happen in (as annotate says) revid:'<email address hidden>' but in revid:'<email address hidden>/june.mysql.com-20071101062017-58064'.

It is possible to view the diff output for that revision with bzr diff and bzr gdiff.

[Jelmer Vernooij (jelmer)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Daniel Fischer wrote:
> Copying from an e-mail about this problem that I wrote:
>
> It appears to be a bzr gannotate / bzr annotate bug. The revision
> that annotate shows for the location mentioned in the bug report is
> an empty merge changeset. The actual change did not happen in (as
> annotate says)
> revid:'<email address hidden>' but in revid
> :'<email address hidden>/june.mysql.com-20071101062017-58064'.
>
> It is possible to view the diff output for that revision with bzr
> diff and bzr gdiff.

Since you mention it also affects bzr annotate:

  affects bzr

Cheers,

Jelmer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBSDb56Qy0JeEGD2blAQKABAP/eDf6NCu0vxa8Aa9xmFhsquSAE+qox+qU
ZnpVvIRV/01EppdUUaBFO93Q4kXgFjCoB0abgJd8AHnwD7GEjh2nkqOjFlpPVnBf
U9vIv4FZeNU5fa66QtZ2YidqS6lPLIISj5ZniKmhmcXDduN3ItIXqzeuSqZ+BxEQ
KzacxVh4aaU=
=PEFB
-----END PGP SIGNATURE-----

[Aaron Bentley (abentley)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Daniel Fischer wrote:
> Copying from an e-mail about this problem that I wrote:
>
> It appears to be a bzr gannotate / bzr annotate bug. The revision that
> annotate shows for the location mentioned in the bug report is an empty
> merge changeset. The actual change did not happen in (as annotate says)
> revid:'<email address hidden>' but in revid
> :'<email address hidden>/june.mysql.com-20071101062017-58064'.

When multiple revisions introduce a line, we assign the annotation to
the revision that merged those revisions.

Unless you've investigated and shown that this didn't happen here, I'd
assume it did.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFINvx60F+nu1YWqI0RAhA2AJ0d0DR0FG+Rn04Ac8CdbED4NLbjVgCeKjDy
BfGwWQlibhQe1WAapqExosk=
=7MKD
-----END PGP SIGNATURE-----

[Daniel Fischer (dannythefool)]

Aaron,

You're right. However, this behaviour is contrary to what bzr annotate is documented to do, i.e. show the revision that introduced the change. In this case, both merged branches already had the line. Therefore, the merge changeset is decidedly not the revision that introduced it to anywhere. Furthermore, it is empty, and provides no clue as to what was changed or when. Displaying it is pointless.

The behaviour of that certain other RCS that this branch was converted from is to show the oldest revision that has the line. The same is necessarily true for CVS etc.

The optimum, IMHO, would be showing all of the revisions that introduced the line at some point.

Daniel

[James Westby (james-w)]

Hi,

I'm confirming the bug in bzr-gtk, as it is a real problem there,
as you can't double click to get to a diff as normal. I think that
should be fixed somehow.

As for bzr, I don't think it's too much of a problem for annotate,
as it doesn't make it so easy to get between the annotation and
the diff, but if it does indicate a revision where the diff doesn't
touch that line it is confusing at best.

Thanks,

James

[John A Meinel (jameinel)]

I have a branch which introduces different "Annotation Policies". Basically, different ways that you can resolve ambiguous lines.

I would recommend changing the default to a specific policy (I'm calling "right-head"), which should handle this case, causing the revision_id a line is marked with to match *a* revision that introduced the line.

[John A Meinel (jameinel)]

I believe this can be considered "Fixed Released" in bzr 1.6rc2 (thus 1.6 final)

[John A Meinel (jameinel)]

I don't think bzr-gtk needs to worry about a workaround anymore.

[GuilhemBichot (guilhem-bichot)]

I confirm that with bzr.dev this problem does not happen anymore for the "my_error()" line I gave in example. Thanks for the fix.