Rescan vs Reindex of FishEye repository, retaining availability

We interface FishEye with Perforce and present a extensive code hierarchy. As the underlaying hierarchy changes, the include/exclude rules must be revised to include new code branches. By default this requires a reindex, which may take us days to complete. Wondering if it might be possible to simply change the include/exclude rules, then "rescan" specific change list numbers starting with the one used to create the new branch and going through something after the current highest submitted change. And if that would properly incorporate the new branch into the FishEye repository, would the rest of (i.e. the existing directories in) the current repository be available for Crucible reviews and Jira views while the rescan is underway?

3 answers

1 accepted

1 vote
Accepted answer

Rescan only changes metadata associated with a changelist - namely the author, date and changelist description. It cannot change the repository structure or included files in a changelist.

Just tried adding a new code branch to the includes, saving that, then "rescan" of the chglists involved and the new branch did not appear at all. Seems rescan does not fully reprocess and reindex the "scanned" chglists.

:( So it may retain the availability, but it did not achieve the desired goal.

So my next thought is wondering *IF* I remember to add the rule for the new branch before I create it in Perforce, and save and restart (not reindex) the repository, if that will properly include the new branch during the scheduled incremental scan.

For me, the main performance problem I was having with reindexing seems to have been due to the multiprint option causing timeouts. When I selected the option to disable multiprint things went much better.

As for reindex vs rescan, it would seem the golden rule is that you must reindex if your include/exclude rules will change the visible source directories. However, you can define hidden rules which take effect upon a restart of the repository. So, best to err on the side of including a bit you don't want and then hide specific directories if needed. Or hide an entire naming pattern and then if you decide later you want them, you can just unhide them.

Then before you reindex next time, you might review promoting some of your hide rules into formal excludes.

Suggest an answer

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

Make your Atlassian Cloud products more secure: our NEW admin security guide

Hey admins! I’m Dave, Principal Product Manager here at Atlassian working on our cloud platform and security products. Cloud security is a moving target. As you adopt more products, employees consta...

300 views 0 6
Read article

Atlassian User Groups

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

Find a group

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

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you