ClearCase: FishEye doesn't handle versions that are deleted from a ClearCase VOB

In ClearCase, versions of a file can be deleted from a VOB. This completely removes the version from the VOB and its content or info about the version can no longer be retrieved from ClearCase.

If FishEye has already indexed the version, the version is still displayed in the UI and FishEye will attempt to retrieve the content using cleartool. This will fail with the following error:

fisheye.app com.cenqua.fisheye.rep.BaseRepositoryScanner-handleSlurpException - Problem processing revisions from repo some-repo due to class 
com.cenqua.fisheye.rep.DbException - com.atlassian.fisheye.clearcase.ClearCaseProcessException: Error executing command (cleartool get -to 
/home/fe-user/fisheye_data/var/tmp/699a3eaf.391611e0.8568.00014268d9285526839728504363906.tmp path/to/deleted/file@@/main/branch/2 ) : cleartool: 
Error: "path/to/deleted/file@@/main/branch/2" does not exist, or is not a ClearCase version, or is a checked out version which was removed.
 : Non-zero exit code: 1

The same error can also occur during content indexing if the version is seen during initial/incremental indexing, but is deleted before content indexing begins. In that case the repository in question will stop indexing and display an indexing error.

Currently, the only way to recover is to do either exclude the file using exclude rules in the repository config (in administration), or do a full re-index of the repository.

FishEye should handle this more gracefully.

At a minimum:

• Indexing should not fail if a 'history rewrite' is encountered.
• Getting the content of the file in the UI should not generate an error.

Ideally:

• The file revision is question is also removed (or marked as removed) from the FishEye index.
• The ancestry (parent and child revisions) of the file revision's descendants are updated to no longer point to the deleted revision.