4699: Wrong filtering of opcodes for an interdiff
- Review Board
What version are you running?
2.5.17, but the same issue in the latest RB
What's the URL of the page containing the problem?
What steps will reproduce the problem?
- Original file 'src1'
- 1-st user modify 'src1' in line 6: '-4.0.16' to '-4.0.17' and post this change to RB#1 (rev1)
- 2-nd user modify 'src1' in line 5: '6.0.11' -> '6.0.12' and check in to repository (src2)
- 1-st user update from repository, and revert modified file
- 1-st user modify 'src2' in line 6: '-4.0.16' to '-4.0.17' and post this change to RB (rev2)
What is the expected output? What do you see instead?
in RB#1. inerdiff 2-3 show that line 5 changed
diff 2-1 and 3-1 show line 6 changed
Expected that interdiff will show white space only, and not mark line 5 as modified, because this change has been done by another user
What operating system are you using? What browser?
windows, Ubuntu, Chrome, Firefox,..
Please provide any additional information below.
In function 'filter_interdiff_opcodes', opcodes range: (4,5), the new_range and orig_range: (4,5) in the latest RB revision, and (4,9) in rev 2.5.17
I can provide other cases, where in similar situation, when different source versions in interdiff, the lines that really changed by the user, marked as equal
Please let me know what you think, and I will dig a code to solve this issue
We have a change in testing that should address the filtering issues. They'll be part of an upcoming 3.x release, and may be backported to 2.5.x if stable enough.
I posted review request with fix for filtering issue: https://reviews.reviewboard.org/r/10000/
I commented out call to 'opcodes = self._apply_processors(opcodes) ' , ( so the processors.py file can be removed)
After receiving not filtered interdiff chunks, I created diff chunks, and compare changed lines in both chunks(diff and interdiff)
The Lines from interdiff, that do not exist in diff chunk, marked as 'equal'
The new code is much shorter and clear, and create correct results in all cases
Thanks for the contribution, but as mentioned above, I have a rewrite of the algorith mthat does the right thing. It's aimed for the next 3.0.x release (had to delay it for other reasons).
Was this back ported to 2.5 by any chance?