Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Can I disable the FishEye/Crucible cache?

I've an old FishEye/Crucible installation on a very poorly provisioned server (hand-me-down, out of support, etc). The index/cache for our repository is 20GB. It's a 10+ year old repository with over 100K commits across dozens of release branches. None of the branches were ever pruned, so they all "exist" at the HEAD revision.

I started reading this KB article

I set the starting revision at 80K (roughly, at the last supported version) and the index/cache is already back about 20GB. There's a working directory worth of files for all these branches at EVERY recent revision sad.

Anyway, I was wondering if there's any way to completely disable the FishEye/Crucible cache? My source control server is actually kind of bored and I wouldn't have any problem hitting the network more often.


3 answers

1 vote
lpater Atlassian Team Feb 03, 2015

Hi Anthony,

The cache is the data FishEye builds while indexing a repository. It allows it to show information about the repository files and history without contacting the SCM. As such it can't really be disabled.

As for reducing the size, I think both setting a start revision (to discard an old part of history that you don't need to see in the application) and setting include/exclude rules (to discard branches/directories that aren't needed) are good ideas and should reduce the size of the cache.

For the starting revision - you must have selected "Import without tag information" as the "Initial Import" option. This causes FishEye to build a snapshot of the repository as it existed at the start revision. To do this we checkout each branch, and traverse the directory structure. These checkouts are temporary and should be removed as indexing proceeds. Alternatively if you don't need to see changes before the start revision, you might consider the 'Do not import' setting, which doesn't do this, and only indexes the changes after the start revision. Note that there was recently a bug fixed related to that setting, that would cause it to add the earlier revisions as well (FE-4773). Please upgrade to 3.6.2 or newer if you want to try this option.

Your exclude rules do look good at a glance. These would include trunk, and only the release branches, that arent x.* or y.*.

Best regards,


Thanks for the reassurance! These Import settings sound interesting, but I'm on FishEye 2.4 and won't be able to upgrade for some months (we're sorting out some disaster recovery stuff before upgrading). Are they available in 2.4? I swear I've looked at all the repo settings screens and haven't seen these.

My other option is to use Allow (Process) include/exclude rules. Although, I have to be careful to construct the correct configuration. Given the rules:

When processing includes and excluded, FishEye merges the includes and excludes from the repository itself with those from the repository defaults. The repository's specific includes and excludes take priority over those of the repository defaults. Once merged, FishEye processes include definitions first and then excludes. If there are any includes defined a path must match at least one of those includes to be considered. If there are no include patterns defined, all paths are considered to be included. Once includes have been processed, a path which is a candidate for processing is tested against any defined excludes. If the path matches any of the exclude patterns, the path is excluded and not included in FishEye.


I need to add includes for the release branches that we still support and exclude the unsupported ones. I ended up with something like this...






It's not an "answer" per-se, but I thought of something...

I'll prune the old branches right now and, maybe in a month, we'll have enough history without them to set the index to some very young revision. I have to make sure the team isn't reviewing old code though... I wonder how new revisions (for example, a hotfix commit) to an older branch will work if it's not in the index.


Suggest an answer

Log in or Sign up to answer
Community showcase
Published in Jira

Admins, notify your Jira instance of system-wide changes with the new admin announcement banner

Hi All! We’re excited to share the launch of an announcement banner that lets Jira site administrators communicate directly to their users across their  Jira Cloud instance.  ...

481 views 16 17
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you