The side effect is that the revision number won't be stored anymore.
Scm Activity no longer works for ClearCase
SCM Activity plugin fails detecting the revision with mercurial
CommandLineException: Missing/wrong number of arguments
Unable to retrieve TFS changelog
Can't integrate SCM Activity into Jenkins with a non-Maven java build
Optimisation of initialisation for project with a lot of changesets
Incorrect user identified for Perforce check-in
Revision number cannot be aggregated up to project level for some VCS
Support "-r" parameter for CVS
Allow tracking of newly added or updated source files
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 :
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.
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 !