On Mon, Mar 16, 2009 at 6:31 PM, Christian Hammond <chip...@chipx86.com> wrote:
> So it's really going to depend on the sizes of the individual files
> themselves. If a file is by itself large enough to cause a couple meg diff
> to be generated, there's nothing we can do really do, since that boils down
> to too large a file to show in the browser.
Is there a specific reason why you went with the current diff view,
where you basically get a diff for all files (or a large number of
them) at once? It's actually one of the off-putting UI features among
our team, since it's quite confusing to have so many diffs in a page.
Our pre-reviewboard solution (and current solution, until we iron out
some reviewboard UI issues) is to basically pack the changes using a
custom tool--it packs before/after snapshots of the files, which can
then be viewed using any diffviewer. Needless to say, all diff viewers
display one-file at a time (or at least: one file in its own window).
Modifying the UI to display one diff at a time would potentially save
some loading time, no? It'd also remove the need to split the diff
into several pages. While the user is inspecting a file, you can
silently work on the others in the background.
You received this message because you are subscribed to the Google Groups
To post to this group, send email to email@example.com
To unsubscribe from this group, send email to
For more options, visit this group at