Community
Participate
Working Groups
Instead of returning the size of the new file, the CHANGE_SIZE is recorded as 0, which means that, for example, the 366 new files that user thabeck [1],[2],[3] created in July 2007 do NOT contribute to his LOC stats [4]. [1]http://dash.eclipse.org/dash/commits/web-app/summary.cgi?project=x&type=y&year=2007&login=thabeck [2]http://dash.eclipse.org/dash/commits/web-app/summary.cgi?company=x&type=y&login=thabeck&project=eclipse.equinox [3]http://dash.eclipse.org/dash/commits/web-api/commit-zero-length-changes.php?month=200707&login=thabeck&project=eclipse.equinox&queries=count,detail [4]http://dash.eclipse.org/dash/commits/web-api/commit-count-loc.php?login=thabeck How does this data get from CVS into the database, and where/how can I change this?
Note also that I think deletes/recovers [5] and tag/branch operations may also return a CHANGE_SIZE of 0, which is probably acceptable here. It's just the initial commits that need to be calculated larger, IMHO. [5]http://dash.eclipse.org/dash/commits/web-api/commit-zero-length-changes.php?month=200707&login=nickb
We've a related issue in that SVN does not report lines of code at all. That number is largely invalid at this point. How should we handle this whole issue?
Well, when a new file is created, enter the # of LOC as the LOC of the initial commit -- `wc -l $thefile`. For svn... no clue, I'm still living in Prehistoria with my bronze-age implements and CVS. :)
We don't have plans to work on this bug (i.e., we're ok with how it works) but are happy to accept a patch from the community to add this feature. If you add a patch, please change the priority from P5 back to P3 so it will appear on our queries.
Closing out of date
