Edgewall Software
Modify

Opened 12 years ago

Closed 12 years ago

#448 closed defect (fixed)

Coverage context linking is wrong

Reported by: osimons Owned by: osimons
Priority: major Milestone: 0.6
Component: General Version: 0.6b2
Keywords: Cc:
Operating System: BSD

Description

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?

Attachments (1)

annotation-revision.diff (1.1 KB) - added by hodgestar+bitten@… 12 years ago.
Patch to use revision passed in via HTTP request to retrieve build and coverage information.

Download all attachments as: .zip

Change History (5)

comment:1 Changed 12 years ago by osimons

  • Version changed from 0.5.3 to 0.6b2

Got a new version now :-)

Changed 12 years ago by hodgestar+bitten@…

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

comment:2 Changed 12 years ago by 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).

comment:3 Changed 12 years ago by 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

    diff --git a/bitten/report/coverage.py b/bitten/report/coverage.py
    a b  
    187187                    title='Annotate file with test coverage '
    188188                          'data (if available)',
    189189                    href=req.href.browser(resource.id,
    190                         annotate='coverage', rev=data.get('rev')))
     190                        annotate='coverage',
     191                        rev=resource.version))
    191192        return template, data, content_type
    192193
    193194    # 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)...

comment:4 Changed 12 years ago by osimons

  • Resolution set to fixed
  • Status changed from new to closed

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

Add Comment

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain osimons.
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.