I'm pretty sure it doesn't do this anymore, and I'm real hesitant to support any sort of 'merging', either of data from different tools (which caused our recent bugs) or data on the set of modules by the same tool. (Which might cause new kinds of weirdness, or at the very least make the implementation of the DailyProject classes even more complicated than they are now.) Most importantly, I don't see a compelling reason to allow this flexibility, at least for our 'shrinkwrapped' DailyProjectData classes. It seems to me that we can just say to users, Look---you have to create a 'complete' snapshot of the system when invoking a given tool/SDT combination, otherwise it's just too complicated and bug-prone to analyze.
Right. I would agree with that. I suppose my point was that I noticed that another implementation was doing something different. I couldn't judge whether it was good or bad. I just knew that maybe I should be doing the same thing and was thinking that we shouldn't be implementing things differently.
Hm. hold the phone. I think it does do the merging. I'll have to double check but I think I don't send all my FileMetric data in one bunch. I send it by module. For example, imagine invoking LOCC and the sensor for each hackystat module (hackyCore_*, hackySdt_*, etc). I'm fairly certain that I did _not_ figure out how to send all the LOCC data with one sensor execution. If I must, then my build process will have to change slightly. Note that I think I did add the module mapping into DailyProjectCodeIssue (see HACK-384), because it functions the same way as DailyProjectFileMetric.
By the way, how does our Hackystat build process do LOCC/SCLC and the sensors? Do we run the tools on the individual modules, then run the sensors on all the data at one time?
again more proof that we should have a layer of abstraction above our DailyProject implementations.
thanks, aaron ps.. thats all the Hackystat hacking/thinking I have for tonight. :)
