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

Can I disable the FishEye/Crucible cache?

Anthony Mastrean February 3, 2015

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
Atlassian Team members are employees working across the company in a wide variety of roles.
February 3, 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,

Łukasz

Anthony Mastrean February 4, 2015

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.

0 votes
Anthony Mastrean February 3, 2015

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...

Include:

/trunk
/branches/release

 

Exclude:

/branches/release/x.*
/branches/release/y.*
0 votes
Anthony Mastrean February 3, 2015

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
TAGS
AUG Leaders

Atlassian Community Events