Why is my reverted file still showing as edited in Code Collaborator?

Question

I have a file under review in Code Collaborator (CC) that we'll call "SomeFile.h." In the first revision, I added a few lines of new code to it. In the second revision, all changes were moved to a different file and Somefile.h was reverted, so SomeFile.h should show no changes in the latest revision.

The CC review summary page shows this for SomeFile.h:

I expected to see the "File was reverted" symbol from the below table out of CC's Review Summary Screen manual, which doesn't seem to include the symbol that is actually shown:

Additionally, if I click on the file and view the diff, my old changes are still shown, giving the impression that the file was not reverted. I have tried submitting the changelist both with and without the unchanged SomeFile.h included, but it had no effect.

Why is a file that has no changes from the currently checked in version still shown with the first revision changes and without the "Reverted" symbol?

My version control system is Perforce, its server version is P4D/LINUX26X86_64/2016.2/1468155. Code Collaborator version is 9.2.9200.

Answer 1

CodeCollaborator's documentation (specifically the symbols you have shown in your screenshot) is out of date.

The screenshot you've shown here:

Is of a reverted file. The little blue arrow sweeping up from the bottom left to the top left is the "reverted" symbol in CodeCollaborator.

The reason this file is still present in your review is because someone has commented on it. Specifically, someone has "Accepted" in the Overall section of that file (indicated by the green circle with the white tick in it).

Any file that has comments in it remains visible in the review, even after being reverted. This is presumably to prevent parts of the review discussion from being lost by the file in which the discussion took place being reverted. (This would be a common occurrence if the reviewer raised an issue recommending a file be renamed, for example.)

Depending on your user settings, reverted files that have no comments at all can be hidden entirely. So this may be the behavior you're used to seeing otherwise.

As for why it still shows a diff that includes your changes, this appears to be a design decision on CodeCollaborator's part. The file has been reverted, as indicated on the main review page, so its contents don't really have meaning in the context of the final change anymore.

I agree that this is potentially confusing, since it's easy to miss the blue arrow and think the changes are still present. It does mean that any comments on that file, which will usually have been made while it is in the "changed" state, will remain within the context of the changes that were originally there. It wouldn't be unreasonable for CodeCollaborator to display "This file has been reverted" or something similar instead of the diff, but that's just not how it has been designed to behave.

Answer 2

I'm not very familiar with Code Collaborator, but I'm going to guess that when you "reverted" the changes in Perforce (note that the word "revert" in Perforce refers to an entirely different operation so using the word in this way here is kinda confusing) this was reflected in Perforce as a normal edit, so it's not going to show up in CC as a special "revert" operation. I'm further going to guess that when you see the old changes in the diff they're in the previous version of the file, so your changes did in fact get removed as of the current version.

Perforce does have a native "undo" operation that is stored in the metadata as distinct from an edit -- however, this is a new feature (added in the 2016.2 server) and to the best of my knowledge is not supported by any clients other than the command line. CC itself would probably not display a native Perforce undo as a revert unless it's been updated recently. (If you're a command line user it is very slick though -- the file history will show exactly what revisions were undone, and you can configure the "integrate" command to take an undo operation into account such that you can re-do an undone integrate rather than treating the undo as a simple edit that adds new changes).