alexG

4699: Wrong filtering of opcodes for an interdiff

alexG 
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?


    

  1. Original file 'src1'
    2. 

  2. 1-st user modify 'src1' in line 6: '-4.0.16' to '-4.0.17' and post this change to RB#1 (rev1)
    3. 

  3. 2-nd user modify 'src1' in line 5: '6.0.11' -> '6.0.12' and check in to repository (src2)
    4. 

  4. 1-st user update from repository, and revert modified file
    5. 

  5. 1-st user  modify 'src2' in line 6: '-4.0.16' to '-4.0.17' and post this change to RB (rev2)
    6. 





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
src2.txt 
#define HIG 3
#define MED 2
#define LOW 1
1b15d61928b39a99bc957a80bbd7b0162660d5dad1221e5977ec42eb84a2c17d  avengine/avengine-6.0.12
4a7ae8d042abff0e113a9da9df4356c2054ccde1475c85aedf766dd7641b4067  ipsengine/ipsengine-4.0.16
02dda69f2827d0d2238f2cef8b8e07a0d0453f739c3c94a2e8e3c72dc932e728  vcm-1.385
/*
 * Third-party, where there are differences between 4 & 5 toolchains.

 






 

  rev1.txt
  




  

 


 

  
 
#define HIG 3
#define MED 2
#define LOW 1
1b15d61928b39a99bc957a80bbd7b0162660d5dad1221e5977ec42eb84a2c17d  avengine/avengine-6.0.11
4a7ae8d042abff0e113a9da9df4356c2054ccde1475c85aedf766dd7641b4067  ipsengine/ipsengine-4.0.17
02dda69f2827d0d2238f2cef8b8e07a0d0453f739c3c94a2e8e3c72dc932e728  vcm-1.385
/*
 * Third-party, where there are differences between 4 & 5 toolchains.

 






 

  src1.txt
  




  

 


 

  
 
#define HIG 3
#define MED 2
#define LOW 1
1b15d61928b39a99bc957a80bbd7b0162660d5dad1221e5977ec42eb84a2c17d  avengine/avengine-6.0.11
4a7ae8d042abff0e113a9da9df4356c2054ccde1475c85aedf766dd7641b4067  ipsengine/ipsengine-4.0.16
02dda69f2827d0d2238f2cef8b8e07a0d0453f739c3c94a2e8e3c72dc932e728  vcm-1.385
/*
 * Third-party, where there are differences between 4 & 5 toolchains.

 






 

  rev2.txt
  




  

 


 

  
 
#define HIG 3
#define MED 2
#define LOW 1
1b15d61928b39a99bc957a80bbd7b0162660d5dad1221e5977ec42eb84a2c17d  avengine/avengine-6.0.12
4a7ae8d042abff0e113a9da9df4356c2054ccde1475c85aedf766dd7641b4067  ipsengine/ipsengine-4.0.17
02dda69f2827d0d2238f2cef8b8e07a0d0453f739c3c94a2e8e3c72dc932e728  vcm-1.385
/*
 * Third-party, where there are differences between 4 & 5 toolchains.

 






  


 










 

  

   chipx86

  

 
 

  

    
     

   
   #1
   chipx86


  


  
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.



 








 

  

   alexG

  

 
 

  

    
     

   
   #2
   alexG


  


  
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



 








 

  

   chipx86

  

 
 

  

    
     

   
   #3
   chipx86


  


  
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).



 








 

  

   

  

 
 

  

    
     

   
   #4
   samsun387


  


  
Was this back ported to 2.5 by any chance?



 








 

  

   david

  

 
 

  

    
     

   
   #5
   david


  



  
    


   
  • 
    
    
    -New
    +Fixed
    
   
    •