Sonar SVN Blame fails due to "svn: E200007: Retrieval of mergeinfo unsupported by"

[Dominik Kaspar]

Hi,

I keep getting such errors during my Sonar analysis:

[ERROR] Failed to execute goal org.sonarsource.scanner.maven:sonar-maven-plugin:3.3.0.603:sonar (default-cli) on project <MyProject>: Error when executing blame for file path/to/some/File.java: svn: E200007: Retrieval of mergeinfo unsupported by 'https://my.company.org/svn/trunk/MyProject/path/to/some/File.java' -> [Help 1]

I've read a lot about the problem, especially what's written on https://docs.sonarqube.org/display/PLUG/SVN+Plugin

Our SVN server (1.7.8) and client (1.8.16) versions are well above 1.5.

Also, I can successfully execute the command "svn annotate path/to/some/File.java" manually, it prints out the file content with a revision and author on each line.

However, when I execute the command "svn mergeinfo path/to/File.java", I get such an error:

svn: E195016: 'https://my.company.org/svn/trunk/MyProject/path/to/File.java@50424' must be ancestrally related to 'https://my.company.org/svn/trunk/MyProject@50420'

Thus, I guess the mergeinfo capability itself is supported, but causes this strange error that I have no idea how to resolve.

Is anyone able to give me some hints?

Regards,

Dominik

[Dominik Kaspar]

Hi,

I have to restate my question, because it seems that I get this error not because of a mergeinfo problem but only because SVN is checked out from a server that is behind a proxy.

When the SVN checkout of the project's code base is done directly via the hostname of the SVN server, the Sonar analysis works with the -Dsonar.scm.disabled=False option and all the blame information is correctly being gathered!

So basically, instead of such a checkout via HTTPS...

https://my.company.org/svn/myproject

... I have to check out via HTTP and provide hostname and port number, then the Sonar SVN Plugin succeeds:

http://host123.mycompany.org:<svn_port>/svn/myproject

Is this a known issue?

Are there ways to teach the SVN Plugin to work with HTTPS or configure another host URL for it?

Regards,
Dominik

[Dominik Kaspar]

Any update on this one?

Has the SVN plugin ever been used through a secure proxy?

Any known issues with that?

Regards,
Dominik

[Julien HENRY]

Hi Dominik,

We are using the SVNKit library under the hood, so it might be an issue on there side. There was some new versions of the library and we are about to release a new version of the SonarQube SVN Plugin. I'm not sure it will fix your problem but you can give a try by using this artifact:

https://repox.sonarsource.com/sonarsource-public-builds/org/sonarsource/scm/svn/sonar-scm-svn-plugin/1.6.0.851/sonar-scm-svn-plugin-1.6.0.851.jar

Another way to investigate is to download the standalone SVNKit command line tool (that tries to offer the same features than the native svn CLI) and run blame command directly.

++

Julien

[Dominik Kaspar]

Hi Julien,

Unforntunately, installing sonar-scm-svn-plugin-1.6.0.851.jar did not make any difference. I still get such errors:

Error when executing blame for file src/main/java/.../dokaspar/public/HelloWorld.java

Do you have an idea what exact command the SVNKit is issuing at that time of querying the blame info?
I would like to exactly reproduce the problem, but strange enough, just after I get the above errors, executing "svn blame src/main/java/.../dokaspar/public/HelloWorld.java" works perfectly fine.

Is "svn blame <file>" not what happens internally?

Also executing "svn mergeinfo src/main/java/.../dokaspar/public/HelloWorld.java" doesn't lead to errors.
Only the Sonar analysis keeps failing...

Cheers,
Dominik

--
You received this message because you are subscribed to a topic in the Google Groups "SonarQube" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sonarqube/1xDuZCFLn1I/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sonarqube+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/d561854d-b9f0-4f57-8c98-35a51abc83ee%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Julien HENRY]

Hi Diminik,

As as said we are using SVNKit internally. So you should try to reproduce using the jsvn command that is in the standalone SVNKit distribution:

https://www.svnkit.com/org.tmatesoft.svn_1.9.0.standalone.zip

We are using the --use-merge-history option so you can try:

jsvn blame --use-merge-history <your file>

Julien Henry | SonarSource

Developer

https://sonarsource.com

[Dominik Kaspar]

Hi Julien,

Thanks for the pointer. The --use-merge-history flag is really what makes the difference! I can now reproduce this error with one single command.

The blame command alone itself works via jsvn, too, but as soon as I use --use-merge-history, the error "svn: E200007: Retrieval of mergeinfo unsupported" appears.

I'm certain that our SVN server supports mergeinfo, so I don't understand what's wrong in my setup.

When checking out my SVN project directly via http://svn-server:port/svn (instead of https://myproxy.com/svn) everything works and Sonar is full of author names.

I guess I have to look further into SVNKit and ask for help there...

Except you have some other ideas, maybe?

Regards,

Dominik

[Dominik Kaspar]

Small update: I just realized that SVN itself has that --use-merge-history flag.

And interestingly, "svn blame --use-merge-history <file>" does NOT lead to an error, while the exact same thing using jsvn does.

Cheers,

Dominik

[Julien HENRY]

You can try to enable verbose output from SVNKit to get more details about network operations:

https://wiki.svnkit.com/Troubleshooting

You can  also try to open an issue on their bug tracker, but I guess they may ask for a way to reproduce, or at least debug logs:

https://issues.tmatesoft.com/dashboard

Julien Henry | SonarSource

Developer

https://sonarsource.com

[Dominik Kaspar]

Hi Julien,

Thanks for your advice.

I was able to switch on verbose output and saw that our proxy does some optimization merging multiple HTTP 'DAV' headers into one.

Unlike native svn, SVNKit seems to be unable to parse capabilities out of such a compressed header.

I've opened an issue here: https://issues.tmatesoft.com/issue/SVNKIT-712

Regards,
Dominik

To unsubscribe from this group and all its topics, send an email to sonarqube+...@googlegroups.com.