Uploaded image for project: 'Subversion'
  1. Subversion
  2. SVN-1966

libsvn_diff needs 'non-minimal-diff' mode.



    • Improvement
    • Status: Closed
    • Critical
    • Resolution: Fixed
    • all
    • 1.7.0
    • libsvn_diff
    • None


      I've got two OpenOffice XML files here, each about 9 megs in size. The second file was produced by simply adding a "2" to the beginning of every third line (...we used a tiny python script to do the transform.)

      When I compare the two files using GNU diff, it takes 14 seconds.

      When I compare the two files using libsvn_diff, it never finishes... or rather, I killed the process after 20 minutes when I noticed the memory footprint had grown to 128megs and was still growing. The footprint was only ~20 megs for the
      first 10 minutes, which is expected behavior (about 2x the size of the file), but I have no idea why the footprint started growing after that.

      I'm using the subversion/tests/libsvn_diff/diff-test binary, by the way.

      I'm attaching the two XML files to this mail for people to reproduce.

      Sander, any idea what's going on? I know that libsvn_diff is sometimes a bit slower than gdiff, but this scenario seems way out of whack. Cmpilato and I discovered this bug when a Collabnet customer attempted to run 'svn merge': the
      client started running svn_diff_diff3() on two 8 meg XML files similar to this one (with a similar density of changed lines)... and after 20 minutes, the server just timed-out and closed the socket... presumably because the socket filled up with the REPORT response and the client stopped reading from it.

      Anyway, I hope this is a simple bug in libsvn_diff...


        1. 1_xmlfiles.tar.gz
          1.49 MB
          Ben Collins-Sussman



            striker Sander Striker
            sussman Ben Collins-Sussman
            0 Vote for this issue
            1 Start watching this issue