Thus, the way to control which tool's size data appears in the dailyprojectdetails is to control when the tools run. In the case of Hackystat, we probably want to run LOCC first and SCLC second so that SCLC data appears in the drilldown.
Just to be sure, technically you mean run the sensors right?
By the way.... I'm increasing convinced that we need a DailyProject redesign.
A while ago I noticed that DailyProjectJavaFileMetric (sinced changed, so I don't know if this still applies) had a mapping for modules. This means that someone can send data from a couple of modules and update those values instead of wiping out the whole snapshot (see HACK-387 ). This mapping is unique and sounded like a good idea. Now we have tool mapping something I wanted to do with CodeIssue (see HACK-380).
Anyway, I think our DailyProject representation should help us abstract these data organizations for us so we don't have to implemented for each DailyProject type.
Something to think about.
thanks, Aaron
At 04:32 AM 5/24/2006, you wrote:
Greetings, all,
I think I'm on track to fix the problems with FileMetrics reporting. The root cause of both the weird totals (HackyInstaller) and column headers (details) had to do with the original approach of trying to "merge" metrics from all size counting tools. This not only created these bugs, but in retrospect is semantically inappropriate--you can't assume that one tool will count LOC the same as some other tool, so to mix the two together in a report just doesn't make sense. (As usual, I am pretty sure that I am the one that proposed that approach, so it's my bad.)
My new approach is as follows:
(a) With respect to the DailyProjectFileMetrics instance, it will still gather the latest snapshot of size data from all tools. What this means is that if you want to write a reducer or a custom hackystat analysis that says, "I want to look at LOCC size data", you can do that. You can still send size data from both LOCC and SCLC regarding a project.
(b) With respect to the DailyProjectDetails report (summary and drilldown), the new approach is to find the tool that sent snapshot data last for that day, and present only that data. Also, the report will be altered to show the name of the tool in the drilldown so you know where the data came from. (this isn't a bad idea for all of the data in the drilldown, actually. For example, it might be nice to know if coverage data came from Emma or JBlanket.)
Thus, the way to control which tool's size data appears in the dailyprojectdetails is to control when the tools run. In the case of Hackystat, we probably want to run LOCC first and SCLC second so that SCLC data appears in the drilldown.
I've got some more hacking to do to finish this off, but I am getting the drilldown to work correctly on data that was messing it up before, so I think we're in good shape.
Let me know if you see any issues with this approach.
Cheers,
Philip
