nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Rescan vs Reindex of FishEye repository, retaining availability

Mark Pottorff

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?

Accepted answers

Conor

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.

All comments

Mark Pottorff

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.

Conor

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.

Mark Pottorff

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.