We went with this method because it was similar to our existing method
we used at VMware, and we wanted to provide a smooth transition. This
actually works out quite well for us still.

You can set 1 diff per page in the Diff Viewer settings in the admin
UI, but the file listing only shows the current page right now. This
can be changed to show every file in the diff, if someone modified the
code a bit (and we'll gladly accept this), at which point it'll be
similar to what you proposed.

Different organizations have different needs and this is an area where
we want to be flexible but can't break existing behavior. But I
believe making the above happen will greatly improve performance for
these use cases where massive diffs are put up for review.

Christian
On 3/17/09, Muhammad Haggag <mhag...@gmail.com> wrote:
>
> 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.
>
> Regards
> --
> Muhammad Haggag
>
> >
>


-- 
-- 
Christian Hammond - chip...@chipx86.com
Review Board - http://www.review-board.org
VMware, Inc. - http://www.vmware.com

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"reviewboard" group.
To post to this group, send email to reviewboard@googlegroups.com
To unsubscribe from this group, send email to 
reviewboard+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/reviewboard?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to