A changelist is a generic SCM concept representing a set of changes in version control. Changelists for some SCM systems like Perforce and Subversion are atomic entities, representing a single unit of changes that occur at the same time. Other SCM systems have changelists that accumulate changes to file versions over time, allowing multiple changes (versions) of any given file within the same changelist. Some examples of this latter type of changelist are ClearCase Activities and PTC Change Packages.
For these multiple-version changelists, the changelist represents an accumulation of changes to each of the source files in it. In most cases, in the context of a review or in thinking about what the changelist represents, users are interested in the difference represented by the accumulation of changes in the changelist, that is, for each source file the difference between the latest version occurring in the changelist and the version content that existed before the first change in the changelist. Collaborator calculates differences based on this, when a multiple-version changelist is uploaded to a review.
This can be confusing in some circumstances. If an added file is part of the changelist, and there are subsequent changes to that file in the changelist, then uploading this changelist for review will result in the latest change to that file appearing as an add in the changelist. In other words, it will have no predecessor. In an SCM system where added files are always version 1.1, a review of a changelist having version 1.5 of a file with no predecessor is incongruent with the versioning of the SCM system. Yet this is exactly what the accumulation of changes to that file in the changelist represent - a sum total of changes that did not exist before the changelist.
While it might be possible to find and upload all versions of each file that occur in a multiple-version changelist and make them available for comparison in Collaborator, in our experience this makes for an unnecessarily complicated review - this is less of a peer review feature and more of a version history browser feature. If a review is to be conducted on successive revisions to a file in this way, the review should be conducted at each iteration of the changelist. Uploading the same changelist to the same review as each successive set of changes is made as part of the rework step of the review will result in all of the versions of each file being available in the it, and each version being available for inspection by the other review participants.