| Summary: | Checking in a new file to CVS results in a CHANGE_SIZE == 0 | ||
|---|---|---|---|
| Product: | [Technology] Dash | Reporter: | Nick Boldt <nboldt> |
| Component: | Commits Explorer (Retired) | Assignee: | Project Dash Incoming bugs <dash-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P5 | CC: | Ed.Merks, karl.matthias, nboldt |
| Version: | unspecified | Keywords: | helpwanted |
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
|
Description
Nick Boldt
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 |