Fisheye errors on + or %2B in svn url

[Aaron Tomosky]

I know this is really more of a problem with apache and our svn server and the fact that someone made a plugin with a + in the name

http://code.google.com/p/gmaps-api-net/source/browse/trunk/src/packages/Newtonsoft.Json.4.5.11/lib/

Anyway, to try to get around the errors in fisheye, I added an exception: **/Newtonsoft.Json.4.5.11/**

however this doesn't stop the errors and the repository scan stays paused

[Aaron Tomosky · Accepted solution]

Here is the result of the support ticket for reference incase anyone else is getting this error:

The original package is:

http://code.google.com/p/gmaps-api-net/source/browse/trunk/src/packages/Newtonsoft.Json.4.5.11/lib/

It has + signs in a folder name: portable-net40+sl4+wp7+win8

A developer used nuget to get packages and when the whole project was saved in our svn it was saved as:
portable-net40%2Bsl4%2Bwp7%2Bwin8

I don't know exactly how this happened if it was pushed with visual studio or tortoise, but probably tortoise and probably 1.7.somthing

if you check it out, it shows as + signs
if you view over http it double encodes into portable-net40%252Bsl4%252Bwp7%252Bwin8
if you try to view it over http with + signs it gives a 404

This is what fisheye runs and it errors because it looks for the + version (rev #2 is when this package was committed):
svn info -R -r 2 http://../packages/Newtonsoft.Json.4.5.11@2

Steps to fix:

check out the repo using tortoise 1.8.3 (it checks out as +)
copy the folder out of the repo
commit the delete (it deletes the %2b version)
copy the folder back into the repo
commit (it commits the + version)
in fisheye edit the repo and under "SCM Details -> <label> Start Revision</label>" set it to the current repo version.

I haven't figured out how to fix this in the past so that the old revisions can be scanned. Fisheye sends the svn info command for every revision since the beginning (or since the start revision). The excludes section has NO EFFECT on this svn info command. Files/folders are only excluded after the fact.

[Conor]

Could you indicate what version of FishEye you are using?

I connected FishEye 3.2 and FishEye 3.3 to the repo above and did not have any problems.

It would help to know the versions, whether you are using natve JavaHL or the bundled svnkit and the stack trace of the exception you are hitting.

[Aaron Tomosky]

I was on 3.2 and Today upgraded to 3.3, same problem. I haven't changed any svn settings in fisheye so it looks like it's the default JavaHL. Settings:

The bundled Subversion client, SVNKit, is being used for Subversion operations.
The JavaHL client version is SVNKit v1.8.3.10190.

and the error is:

org.apache.subversion.javahl.ClientException: svn: E160013:

We are not directly connected to that repo, that is a module that our developers downloaded and added to their application code which is stored in OUR svn.

When I browse our internal repo, the url comes up like:

../Newtonsoft.Json.4.5.11/lib/portable-net40%252Bsl4%252Bwp7%252Bwin8/

so apache is urlencoding the % as %25 and leaving the 2B. awesome.

tortoise checks it out as: portable-net40%2Bsl4%2Bwp7%2Bwin8

I really don't want to have my developers rename things or mess with my svn server to get it showing differently since it works with Visual Studio and Tortoise just fine.

My core question is how to get fisheye to just ignore this folder and quit throwing errors.

[Conor]

For me the URL in my browser appears as

/browse/plusrepo/packages/Newtonsoft.Json.4.5.11/lib/portable-net40%2Bsl4%2Bwp7%2Bwin8

Also, when I add an exclude path of

**/Newtonsoft.Json.4.5.11/**

The whole directory disappears (you do need to reindex when you do this).

I agree that you don't want to rename things and FishEye should handle anything in the repo. I would also like to understand if the problem occurs during indexing (you mention the repository pausing) or during browsing or both.

Is it possible for you to bypass the Apache httpd front end and connect directly to the FishEye server to see if the problem is still present there.

At this point, I think the best course of action would be to create a support case at support.atlassian.com

[Aaron Tomosky]

So it appears that the exclude path functions after whatever scanning is happening that gives me the error in the first place. Like it wants to scan the path to see if it should be excluded even though my exclude will obviously match anything in that folder.

I'll create a support case, thanks for your attempted help.

[Aaron Tomosky]

sortof, I put the resolution in my self-answer above

[Darryl Cameron]

Did you ever get a resolution to this issue? I have the same problem.