Opened 12 years ago

Closed 11 years ago

#24 closed task (fixed)

Alternative statistics

Reported by: jari Owned by: peter
Priority: critical Milestone: svndigest 0.7
Component: statistics Version:
Keywords: Cc:

Description (last modified by peter)

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 12 years ago by jari

  • Component changed from core to statistics
  • Summary changed from Alternativ statistics to Alternative statistics

comment:2 Changed 12 years ago by peter

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 12 years ago by peter

Should this be optional using a cmd flag?

comment:4 Changed 12 years ago by jari

  • Description modified (diff)

comment:5 Changed 12 years ago by jari

  • Description modified (diff)

comment:6 Changed 11 years ago by peter

  • Priority changed from major to critical

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

comment:7 Changed 11 years ago by peter

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 11 years ago by peter

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 11 years ago by peter

  • Description modified (diff)

added relationship to #227

comment:10 Changed 11 years ago by peter

  • Status changed from new to assigned

comment:11 Changed 11 years ago by peter

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

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

Note: See TracTickets for help on using tickets.