Today a developer mentioned that SQ flagged a “new” hotspot on code that was a year old, while missing the same issue on code he just committed.
It seems that the new method he added in the middle of the file pushed things down so that hotspot i moved down to roughly where hotspot i+1 was previously. The code used for the hashing was the same, so hashes matched. The upshot is that SQ thought the new code matched an old hotspot we already marked safe, while thinking another old hotspot is actually new.
This isn’t a big deal in this case because we will resolve the “new” hotspot as safe and give it the same comment. But there could be a situation where the hotspots in question have different comments, or even different resolutions. The Issues page of the user guide states:
So obviously the first rule is being applied and matching, so it doesn’t look at the block move information.
Is there a way to configure the analyzer to give more weight to block move information? If we point it to our SVN repo (right now I believe that is turned off) is it more likely to notice that the new code was inserted in the middle, and align the hotspots better? (In this case, ‘svn blame’ recognizes the hew code as being newly inserted.)