Skip failing svn blame on file (E175002)

I’m working in a large scale project which is using svn. We are trying to setup sonarqube for multiple maven (java) projects.
In one maven module we could observe a failure which can’t be fixed easily.
Our svn repository is very complex and some parts are deeply copied including history and some others not.
Therefore not all parts of a revision are available and also some other dirty hacks existing using the svn.
This means we haven’t full access to the full history of some files (around 20 of million source files).

During the analysis we got the following error message (path changed for privacy):

[main] [ERROR] Failed to execute goal org.sonarsource.scanner.maven:sonar-maven-plugin:3.5.0.1254:sonar (default-cli) on project Aggregate-XYZ: Error when executing blame for file folder/subfolder/Abc.java: svn: E160006: No such revision 1145401
[main] [ERROR] svn: E175002: REPORT of '/svn/extern/!svn/bc/714526/folder/subfolder/Abc.java': 500 Internal Server Error (https://example.com)
[main] [ERROR] -> [Help 1]

The same error could be observed using svn in the console

svn co https://example.com/svn/extern/folder/subfolder
svn blame --use-merge-history Abc.java

Result:

svn: E160006: No such revision 1145401

The repository itself is not corrupt, it is a special copy strategy.

We can’t change our svn. We need a flag in sonar to skip these errors.
I’ve located the part in the sonar-maven-plugin.

We got an exception from line sonarqube/SvnBlameCommand.java at master · SonarSource/sonarqube · GitHub which is correct.

I need a try/catch around the blame(clientManager, inputFile, output) in line sonarqube/SvnBlameCommand.java at master · SonarSource/sonarqube · GitHub

This could be provided as System property / environment variable or something else to ignore exceptions using svn blame.
Currently we have no other possibility without patching the sonar-maven-plugin and maybe someone else has this problem also in the future.

I’ll hope you understand the feature request and maybe like to add an official solution.

Thanks in advance and many regards from Berlin, Bernard

Hi @bernardladenthin

The repository itself is not corrupt, it is a special copy strategy.

I would be interested to know more about that. Is there a way to reproduce this state in a sample SVN repository?

I’ve located the part in the sonar-maven-plugin.

I’m pretty sure this is not in the sonar-maven-plugin :slight_smile:

I need a try/catch around the blame

The problem is that SonarQube need blame information for multiple features: leak period, issue auto-assign. If we “just” silently ignore errors, it may lead to functional issues.

If it is not possible to execute blame on this particular project, maybe you could disable the feature, using property sonar.scm.disabled=true. This will force SonarQube to fallback on a different mechanism to compute the leak period (and not have any issue auto-assign), but at least it will be consistent.

I’m not sure it is good to mix files having blame available and some having not.