4159: expandable udiff view as alternate to side-by-side

darrenmoffat 
What version are you running?


2.5.2


What's the URL of the page this enhancement relates to, if any?




Describe the enhancement and the motivation for it.


We are evaluating ReviewBoard as an alternate to our how grown "webrev" tool.  In "webrev" we have multiple views of the change available:


cdiff - a raw cdiff style

wdiff - a unified diff with line numbers and context expansion

sdiff - side-by-side view like ReviewBoard does.

frames - scrolling side-by-side.


The current ReviewBoard side-by-side covers the webrev sdiff and frames views.


This enhancement request is to extend ReviewBoard to provide an additional selectable view for diff review that works like the webrev wdiff.


The reason for this is that some of the files we need to review are better reviewed when you can see the unified diff with the addition of the old and new line numbers.  This is particularly true of some data files that have long lines, they don't lend themselves well to side-by-side review.


You can see an example of webrev output here:


https://ips.java.net/webrev/barts/21868331/


What operating system are you using? What browser?


OS: Solaris.

Browsers: Firefox, Chrome


Please provide any additional information below.
david
#1 david 
We've discussed this before, but it's not something we plan on adding.
  • -New
    +WontFix
#2 darrenmoffat 
Rather than just saying you won't do it can you please explain why ?  There are some file types or styles of change that really don't review well when all you have is side by side diffs.

If patches for this feature were contributed would you change your stance on this ?


While I appreciate that others might not need this style of review it is a very important feature for us being able to deploy ReviewBoard and if we don't have it then that ends our current evaluation now and we will look for something else.
david
#3 david 
Adding additional diff modes is a massive amount of work with a relatively small gain. The particularly hard problem is how to make sure that comments made against code can translate in a non-confusing way between the different diff modes. We've played around with this problem on a number of occasions but there doesn't seem to be any good solution. It would also involve a lot of restructuring and refactoring of core code, which is always scary.


We'd be willing to look at contributions, but because it would be such a big, invasive change, it would have to be extremely compelling in order for us to accept it.