It seems that when using Crucible with Perforce (I can't speak to other source control systems) that a review can only involve one revision of any given file.

In some cases, a functional change to the code base is made with multiple changelists prior to creating the review.—I want to create one review to review the cumulative effect of a set of related changelists. Some files might appear on multiple changelists.

So I might update foo.c to revision #10 under changelist 500, and later update it to revision #11 under changelist 600. I'd like select both changelists and have the review show the difference between revision #9 and #11. As it is today, I can only get one revision or the other, but not both represented in the difference.

I can understand that if another unrelated change is submitted in between my set of two (or more) changelists, that you can't easily generate a valid diff. In that case, I'd like to see the file listed on the file listed multiple times, once for each consecutive run of revisions.

So for example:

I submit changelist 500:
Foo.c# 2
Foo.h#7

Others submit totally unrelated changelists 501-519

I submit changelist 520:
Foo.c#3
Bar.c#9

Joe submits changelist 530 for an entirely unrelated functional change
Foo.c#4

I submit changelist 540:
Foo.c#5
Bar.c#10

I select changelists 500, 520, 540 for a Crucible review. It should list the following files and differences:
Foo.h (diffed from #6 to #7)
Foo.c (diffed from #1 to #3)
Foo.c (diffed from #4 to #5) Note this file appears twice on the list.
Bar.c (diffed from #8 to #10)

The above process would extrapolate such that a diff might contain a run of several consecutive revisions, and also extrapolate to where a file occurs N times due to N distinct consecutive runs of revisions found on the changelist.

This could be enhanced in stages, where the first stage still only allows each file to be on the review once, but does allow consecutive file revisions (special casing consecutive changelists is mostly useless for us since it rarely occurs in practice that two consecutive changelists are for the same work item.)

Without this, we must always submit an entire change in one changelist (not always feasible) Or expect reviewers to review part of a change in one review and the rest of the change in an other review.