This problem occurs in a very special conditions and it was nontrivial to forge such SVN repository which proves FishEye has a bug here.
This bug occur when all the following conditions apply:
- SVN and FishEye server must run on some Unix/Linux machines (supporting symbolic links)
- directories must include special characters which must be escaped while building URL, e.g + or % (e.g. branches/release-bugA+bugB+bugC)
- there must be a symbolic link inside such directory
- such directory has been moved (svn move) from outside repository (as configured in FishEye) into it (e.g. whole real SVN repository is http://server/svn
, FishEye repository is http://server/svn/projectA
and a directory with symbolic link has been moved from http://server/svn/projectB/a+c
to http://server/svn/projectA
)
The problem is that in such conditions FishEye follows such path in its scanning algorithm which leads to escaping
twice special characters.
So at some moment
http://server/svn/projectB/a+c/symlink
is treated as
http://server/svn/projectB/a%2Bc/symlink
("+" becomes "%2B"), but then incorrectly it becomes
http://server/svn/projectB/a%252Bc/symlink
(now % is unnecessarily escaped).
When FishEye wants to retrieve from SVN repository information using such now corrupted URL it encounters exception and as result repository will not be further scanned at all.
The sample stack trace is:
I am settings priority to critical as it affects existing customers and they have no easy workaround other than excluding whole trees which contain URL-escaped characters.
Final hint: FAIK we don't need to escape + sign at at all. However the problem will anyway occur for other special characters in filenames.
Sample forged SVN repository which at revision 39 (full scan) causes FishEye to choke.
The repository must be configured in FishEye as follows:
Please notice non-empty path attribute in <svn> element.