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

Bug #232188 reported by Anne Mohsen
6
Affects Status Importance Assigned to Milestone
Bazaar
Fix Released
Medium
John A Meinel
Bazaar GTK+ Frontends
Invalid
Undecided
Unassigned

Bug Description

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.

Tags: mysql
Revision history for this message
Daniel Fischer (dannythefool) 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.

Revision history for this message
Jelmer Vernooij (jelmer) wrote : Re: [Bug 232188] Re: double-clicking on some line in "bzr gannotate" says "no such file", shows no diff

-----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-----

Revision history for this message
Aaron Bentley (abentley) wrote :

-----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-----

Revision history for this message
Daniel Fischer (dannythefool) wrote :

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

Revision history for this message
James Westby (james-w) wrote :

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

Changed in bzr-gtk:
status: New → Confirmed
Revision history for this message
John A Meinel (jameinel) wrote :

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.

Changed in bzr:
assignee: nobody → jameinel
importance: Undecided → Medium
status: New → Fix Committed
Revision history for this message
John A Meinel (jameinel) wrote :

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

Changed in bzr:
milestone: none → 1.6
status: Fix Committed → Fix Released
Revision history for this message
John A Meinel (jameinel) wrote :

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

Changed in bzr-gtk:
status: Confirmed → Invalid
Revision history for this message
GuilhemBichot (guilhem-bichot) wrote :

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.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.