Stop using the changelog/revision to determine if the blame information should be updated on a source file

In general not a good idea.

There are two numbers which have impact to scmactivity plugin performance.
1.) number of changesets
2.) number of files to blame

During the first running, scmactivity plugin has to collect all changesets and also blame all files. This could be optimised as I suggest in SONARPLUGINS-1870 .
For the next run, there are two possibilities.
A.) using only blame phase, this means that plugin has to blame all files for every run of plugin.
Disadvantage : if project has a lot of files, it can be really time consuming operation.
B.) compute files to blame from changesets and blame only changed file. This is today solution.
Disadvantage of this solutions depends on complexicity of computing changelog. This is cheap for changeset based VCS like Mercurial/GIT, but really expensive for file based VCS like CVS.

I suggest give user possibility to choose the way how to compute list of files to blame.
Maybe You can expand of my idea from SONARPLUGINS-1870.
Name ot that option can be "use-changelog" with possible values :

• never .... never use changelog, always use blame for all files ( recommended for CVS )
• always... always use changelog, compute blame only for files in changelog ( recomended for small project and VCS with cheap changelog computation )
• not-for-first-run ... for first run don't use changelog, and after initialization use changelog ( recomended for project with many changesets )

If you look at my last patch SONARPLUGINS-1561, there is not a lot todo with this idea.
I could implement this improvement, if you want.

Hi Vladimir, in fact I forgot to mention in the description that we're going to stop using this SCM changelog ... but to replace it by our own mechanism to check what've changed. The goal is to save a hash of the content of a source file during each analysis and to update the blame information on this file as soon as this hash value has changed. So the external behavior of the SCM Activity plugin is not going to change.

Done.

First run with this plugin will have to compute blame information for every file because it has no file hash to compare with.

We could improve this with newer version of Sonar by generating the hashes through a migration.

David, what about situation, when plugin wasn't installed (or inactive for some projects), but migration performed? Thus I would prefer long execution for a first time than magic during migration.

Evgeny, the migration (and I'm not saying we should do it) could compute SHA1 of each file whose source code already stored in the snapshot.

Then we should retrieve blame information only if the SHA1 doesn't change OR we don't have previous blame measure.

ad comparing SHA1 sum

I've made test on my repository ( 4103 java files )

$ time (find src/main/java -name "*.java" | xargs sha1sum | wc -l )
4103

real 0m1.885s
user 0m0.554s
sys 0m0.540s

It could work in accepted time frame.

There is a bug : if you analyse a project three times without changing anything, the blame commands are executed the third time whereas this should not be the case.

Fixed

Same issue

Really fixed this time

Indeed David but the blame data doesn't seem to be copied from one source snapshot to the other. So after second run we don't have anymore SCM information available in the Sonar code viewer

Fixed. (Until next bug)

Manually tested !

ITs done