Opened 13 years ago

Closed 11 years ago

#24 closed task (fixed)

Alternative statistics

Reported by: Jari Häkkinen Owned by: Peter Johansson
Priority: critical Milestone: svndigest 0.7
Component: statistics Version:
Keywords: Cc:

Description (last modified by Peter Johansson)

See also #66, #82, and #227.

Create statistics that shows how many lines of code a developer is responsible for at a given revision (blame for each revision).

Change History (11)

comment:1 Changed 13 years ago by Jari Häkkinen

Component: corestatistics
Summary: Alternativ statisticsAlternative statistics

comment:2 Changed 13 years ago by Peter Johansson

Using the internal blame functionality will be very time consuming here. Blame scales like revision and thus calling blame for each revision will take ~rev2.

Therefore it is essential to fix ticket:5.

comment:3 Changed 13 years ago by Peter Johansson

Should this be optional using a cmd flag?

comment:4 Changed 12 years ago by Jari Häkkinen

Description: modified (diff)

comment:5 Changed 12 years ago by Jari Häkkinen

Description: modified (diff)

comment:6 Changed 12 years ago by Peter Johansson

Priority: majorcritical

This ticket is blocking implementation of several other issues (e.g. sensible Copyright update, a more logical first page).

comment:7 Changed 12 years ago by Peter Johansson

Every non-idiot realizes there is no point calling 'svn blame' for each revisions. For a typical file there are numerous revisions in which the file is not modified. Instead one could use 'svn log' to exctract which revision to run on. However, that approach is not perfect and needs some cover. This is because a file can have a longer history than what appears in the log. This happens could happen, e.g., when the file has been moved around in the file structure.

A better approach than the one mentioned above is to first call log to get a set of interesting revisions. Parse the latest revision with blame. While parsing the blame return note all the revisions, and if it was not already in the set of revisions, add it to the set of revisions.

comment:8 Changed 12 years ago by Peter Johansson

Another issue is whether it is enough to run svn blame on those revisions that have been committed since last run. Naively the answer is clearly yes. But if the answer was yes, I would of course not give this comment. Once again it is svn copy and svn merge that can create some tricky cases. It is not clear for me how these operations work, yet it is clear that they can add some history to a file. At least svn merge can make a revision full of lines that was all empty before.

We have to think of this and perhaps be smarter.

comment:9 Changed 12 years ago by Peter Johansson

Description: modified (diff)

added relationship to #227

comment:10 Changed 12 years ago by Peter Johansson

Status: newassigned

comment:11 Changed 11 years ago by Peter Johansson

Resolution: fixed
Status: assignedclosed

(In [537]) Blame stats is implemented - fixes #24

Note: See TracTickets for help on using tickets.