Coverage context linking is wrong

[osimons]

You are right, Hodgestar. There is something wrong how the revision is fetched, and the resource is not always right.

I noticed this when hitting 'Coverage' context menu for a file in a branch that hasn't been changed in the branch (revision for file is from pre-branching). It would then link to the last revision of the file at its original destination.

That leaves a pretty TracError saying there is no node /path/to/my/file at rev X when browsing ?rev=Y.

So I suppose we should revisit your patch - which I can't find anymore. Using the resource is not always fine, and I suppose that means using rev from req.args if available?

[osimons]

Got a new version now :-)

[hodgestar+bitten@…]

Patch to use revision passed in via HTTP request to retrieve build and coverage information.

[anonymous]

I've attached the patch I'm using at the moment. It uses the revision passed in along with the HTTP request to retrieve the build to use for coverage annotation (and falls back to the latest revision if no revision is passed in).

What this patch is missing is something which allows the user to easily navigate between revisions that have builds (since these are not likely to be consecutive revisions) and a means of notifying the user that the revision doesn't have a build (which is currently indistinguishable from having a build with zero coverage or a build without coverage).

[osimons]

Hmm. Been testing this, and if so it needs more checks as rev can also be empty for HEAD (rev=).

On my up-to-date Trac, using resource still gives the most useful result. That means changing the 'Coverage' context menu item like this:

bitten/report/coverage.py

@@ -187 +187 @@
                     title='Annotate file with test coverage '
                           'data (if available)',
                     href=req.href.browser(resource.id, 
-                        annotate='coverage', rev=data.get('rev')))
+                        annotate='coverage',
+                        rev=resource.version))
         return template, data, content_type
 
     # IHTMLPreviewAnnotator methods

The strange effect is then browsing file where repos is at revision 18 and looking at a file last changed at revision 16, the blame 'Annotate' will have rev=16 but Coverage will have rev=18. I still think that is correct seeing revision 18 (and earlier) will contain the coverage data if builds exist.

The blame 'Annotate' has the unfortunate effect of switching the repos browsing from latest-for-the-repos to latest-revision-for-file, so that once hit I'm browsing the repos at an earlier revision than latest. That is annoying, confusing and unexpected. I don't think that is right.

I'll check this some more before deciding (again)...

[osimons]

Fixed issue with 'Coverage' context menu in [767] (trunk) and [768] (0.6.x).

With latest/recent Trac, the resource.version is the best alternative for getting currently browsed version. For those on older Trac versions, upgrade :-)