I guess that some small improvements like comparing a revision with revision-1 would be just fine.

For now we can use the "compare base with last revision", but what to do if there are multiple commits of the same file in one ticket?
We should be able to compare any revision with a reversion that precedes that one not only the last one

As long as this is not implemented, how do you all workaround it? We have no idea how to avoid it. Sometimes it happens that you have multiple tickets or that multiple people work in the same file.

Without this feature it is becoming more than just an annoyance to our team..

Jesse Jacob's comments about the issue are ill-considered. Many teams work in close proximity on some files, and despite a frequent review process, this problem rears its head. This is by far the biggest drawback of the software and I cannot believe it hasn't been addressed since being reported as far back as 2014.

I've been trialling Review Assistant for our development team and this is the one issue which is stopping me from recommending that we fully license the product.

I am not sure this is just due to a bad, or even slow, review process. We have situations where reviews are created when initial changes are pushed, so there is no issue with the sliders/diffs there, but if rework is required we want to add the changeset for the rework to the original review to show it has been done, this can easily result in the changesets spanning other changes.

If the original review is for change 123, we see the slider showing 122-123, the review is rejected with rework required - when the rework is completed it is change 127, the slider will show 122-123-127... I would suggest it should show something like 122-123-126-127, so you can see the changes just due to the new change.

It is possible to do this manually, but it can cause problems with which review changeset 126 is associated with (it may have been associated with a closed review, adding it to a new one ends up flagging the changeset as being associated with an 'open' review again

I think you're trying to make the tool patch over a bad code review process...I don't see many people needing this feature if they're doing frequent reviews. In my experience this problem crops up when people wait a very long to time to post a review a review--so long that other people can make unrelated changes to the same files as you've described. This is a pattern you should try to avoid by having people submit reviews more frequently so the changes being reviewed are more granular.

This is described in greater detail in this thread on the forum: http://forums.devart.com/viewtopic.php?f=49&t=29936&sid=c018de2c812a3ccb85abf827cc887ad3

Quoting part of the post:

If a revision is added, say 123, and the review is submitted, then the slider control will show 122-123. This is fine when choosing the 'Compare Base and Last Revisions' as we can see the intended diff for the work done.

However, if another revision is added, say 987, for some review rework, then the slider control only allows me to select the revision range of 123-987. This means when I select 'Compare Base and Last Revisions' it is showing ALL changes made by ALL authors in the revision range.

This makes it difficult to determine what should be reviewed, and means comments are being added to the wrong review (where another review exists for a code change highlighted in the diff).