Opened 17 years ago
Closed 15 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 )
Change History (11)
comment:1 Changed 17 years ago by
| Component: | core → statistics |
|---|---|
| Summary: | Alternativ statistics → Alternative statistics |
comment:2 Changed 17 years ago by
comment:4 Changed 16 years ago by
| Description: | modified (diff) |
|---|
comment:5 Changed 16 years ago by
| Description: | modified (diff) |
|---|
comment:6 Changed 16 years ago by
| Priority: | major → critical |
|---|
This ticket is blocking implementation of several other issues (e.g. sensible Copyright update, a more logical first page).
comment:7 Changed 16 years ago by
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 16 years ago by
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:10 Changed 16 years ago by
| Status: | new → assigned |
|---|
comment:11 Changed 15 years ago by
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
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.