Current algoritm for first run of sonar-scm-activity plugin contains three main steps :
1.) create full changelog history list ( call maven-scm-plugin method changelog, which return list of all changesets with list of all modified files)
2.) for each file in working directory call maven-scm-plugin method blame
3.) put scm changelog statistic for project to sonar DB ( last commit, last date of commit )
When the project contains a lot of changeset with a lot of renames/deletes of files, there are two kind of problem :
a.) timeout with communication with Sonar Server DB
b.) there could be a OutOfMemoryException
I run into this problems because my Mercurial repository contains 55-thousand of changesets / 10 years development.
I suggest this way of optimisation :
A.) new configuration parameter : optimise-first-run ( default false )
B.) if optimise-first-run == true and lastChangeSet is null then
B.1) skip changelog generating
B.2) do only blame phase
B.3) during blame phase compute number of commits/lastAuthor/lastCommitDate
B.4) wrote computed measures to SonarDB
This optimization has one drawback, total number of commits/lastAuthor/lastCommitDate are computed only from existing files, not from changelog history. But I think, that is better to have bad starting numbers than nothing, because for big plugin the sonar scm-activity may not finish.
User has still option to switch this functionality on/off. Default shoud be off.