Fisheye copes poorly with branch or tag deletions

From previous correspondance with Conor MacNeill:

>
> Does not cope well with branch/tag deletions
>
> One of the operations which regularly causing blocking of repository
> scanning is the removal of branches or tags within a Subversion
> repository.
> I don't know why this is the case - I opened a query with Cenqua about
> this - they weren't actually able to tell me the answer as to why it takes
> so long.

From an external view, a Subversion respository can appear huge. i.e.
if you performed an svn listing (ls) on the root of a Subversion
repository, which contains 10 branches and 100 tags, the repository will
appear to be about 111 times its actual size. This is not a problem for
Subversion itself, internally, as its access is predominantly sequential
(with respect to the directory hierarchy). As it navigates a path, it
can follow copy links - so called cheap copies. As an indexer, FishEye's
access to the directory hierarchy is predominantly "random access".
Searching with FishEye would be more difficult if it were navigating the
directory hierarchy sequentially.

We are actively researching whether we can take advantage of "cheap
copy" style linking within FishEye's index to better handle the way
Subversion works. In other word, we do recognize the problem and we are
working on solutions.

One of the approaches taken within FishEye to mitigate the problem is to
recognize tags as such and to tag the original file's entry in the
FishEye index. Effectively the tagged directory hierarchy is virtualized
by tagging the entries for the source of the tag. This keeps the size of
the FishEye index down significantly but does mean that FishEye needs to
know when a copy represents a tagging operation.

Workarounds:

1. Add exclude rules in order to make Fisheye ignore the paths from the branches and tags that have been deleted.
2. Set a start revision to start indexing from a particular revision.
3. Split a single large repository into logical components (e.g., by project or by product).
4. Change the repository definition so as to look at a subset of your repository by setting a path within your repository that you wish Fisheye to index.
5. After trying one or more of the suggestions above, saving changes and exiting the repository administration panel a modal window will be presented saying that the repository needs to re-indexed for changes to take effect, and offering two options:
   • Perform now will immediately erase the repository cache indexed thus far and will start re-indexing the repository from scratch.
   • Ignore will keep everything indexed thus far, but you need to stop and start the affected repository to make Fisheye ignore the excluded paths from now onwards.
6. As a general advice, you could benefit from a way faster indexing speed by using file protocol instead of HTTP / HTTPS for connecting to the repository. According to the Best Practices document, HTTP and HTTPS are the slowest protocols. You can switch to file protocol by either:
   • Migrating Fisheye to the server where Subversion is installed, or
   • Using the svnsync utility to mirror the remote repository onto the server where Fisheye is installed.
7. The most important aspect for a large-repository deployment will be disk I/O speed. You definitely want a fast local HDD for Fisheye's cache. Note that NFS and SAN are not supported. Perform the disk access speed test and compare your benchmarks with the table shown in the section Grading the Results from that document in order to make sure that the HDD speed on the Fisheye server is at least OK for all file operations.