Uploaded image for project: 'FishEye'
  1. FishEye
  2. FE-314

Fisheye copes poorly with branch or tag deletions



    • Type: Bug
    • Status: Long Term Backlog (View Workflow)
    • Priority: Medium
    • Resolution: Unresolved
    • Affects Version/s: 1.4.2, 1.4.3
    • Fix Version/s: None
    • Component/s: None
    • Environment:


      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.


      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.


          Issue Links



              Unassigned Unassigned
              772198ccd59e David Grierson
              46 Vote for this issue
              30 Start watching this issue