Svn: E175002: PROPFIND of blah 400 Bad Request

I am using atlassian fisheye to scan repos for code reviews. I am seeing this error in my repo scan.
Repository paused due to error com.cenqua.fisheye.rep.RepositoryClientException: org.apache.subversion.javahl.ClientException: svn: E175002: PROPFIND of ‘/scm/repo/AED3/aed_star_oe/!svn/ver/7981/linux/trunk/meta-freescale/recipes-core/init-ifupdown/init-ifupdown_%.bbappend’: 400 Bad Request

I tried excluding the pathname in fisheye, but my patterns don’t seem to work. I keep getting this error.

thanks for letting us know! I suspect, the problem happens because ‘%’ character is not escaped to ‘%25’. May I ask you to conduct an experiment? Temporary rename or remove this file to see if this solves the problem.

Another thing I would ask you about: could you share more logs on this error, e.g. the stack trace or operation that fails. SVN API operations are similar to their command line counterparts (like ‘svn info’, ‘svn status’). Knowing which exactly operation fails would help me to reproduce and fix the problem.

Finally, may I ask you which SVNKit version fisheye is using? You could deduce that from SVNKit JAR filename.

I’ll try to reproduce and fix the problem, any information would help.

Hi Dmitry,

I have a test instance of the newer version of scm-manager running, so I setup fisheye to scan a mirror of the one that is failing in my production setup.

The new version of scm-manager has no problem with the % character, so I assume it is using a new version of SVNKit which contains the fix for spaces in pathnames that I reported a while back. This bug was addressed/fixed and merged to SCM Manager master branch.

Thank you very much for responding to my query. But I just have to upgrade my production setup and things will work better for me.

Thanks for the information! It seems SCM Manager has its own patched version of SVNKit. I’ll review this change and if it is correct, I’ll make a similar change in the vanilla SVNKit version.

For those who has the same problem: I’ve created SVNKIT-768 for it. The fix will be included into the next SVNKit release (1.10.8).