Labels: Type-Defect Priority-Medium
New issue 1890 by matthew....@intel.com: Hiding/non-presentation of
whitespace-only/EOL-changed files is confusing
*NOTE: Do not post confidential information in this bug report.*
What version are you running?
What's the URL of the page containing the problem?
What steps will reproduce the problem?
1. In SVN, create a diff where the end-of-line style is changed, and
submit that diff to reviewboard.
2. Create a review using that diff. Reviewboard will show no files in the
What is the expected output? What do you see instead?
I expected to see the file with "0 changes" listed, as was done in earlier
versions of RB.
By showing the file, even with "0 changes" RB tells the reviewer that the
file was changed (somehow), andeven if RB can't explain/present the change,
that the reviewer should be aware that something's different. If the
changes are entirely superfluous, the reviewer can request that the file be
removed from the change set--also a useful result of reviewing changes. If
the changes are significant, the reviewer can examine them for correctness.
Deleting the file from the file list presents a confusing user interface in
the following ways:
a. It is confusing for reviewers to see that (for instance with 10 files
per page) page 1 shows files 1 through 8, but page 2 starts at file
#11. "Where did files 9 and 10 go? This must be a bug in Review Board."
b. Diff submitters don't see some files in the review that they know they
changed, and wonder where they are.
c. Say we have 10 files per "review page". Users suspect something is
broken if they get less than 10 files per page on a
known "not-last-page-of-the-review". If files are going to be hidden, they
should still get a full page of files on each page.
d. When users see less than a page full, they sometimes conclude that
they're on the last page of the review, and conclude the review early.
(Happens when they get interrupted/take a break.)
What operating system are you using? What browser?
Please provide any additional information below.
Perhaps it would be beneficial if the whitespace engine wasn't so `smart',
and that ignoring of wholesale whitespace changes should be
handled "upstream", when/where the diff is generated, and not "downstream"
You received this message because you are subscribed to the Google Groups
To post to this group, send email to reviewboard-iss...@googlegroups.com.
To unsubscribe from this group, send email to
For more options, visit this group at