On 3/27/15, Peter Spjuth <peter.spj...@gmail.com> wrote: > On Fri, Mar 27, 2015 at 8:47 AM, Andy Bradford <amb-fos...@bradfords.org> > wrote: > >> Hello, >> >> While working with some data, I ran into a change in the data that >> the sbsdiff doesn't seem to handle very well (either that or my >> understanding of how it works is wrong). >> >> If I commit both complete files (file revision 1, followed by file >> revision 2), the sbsdiff shows almost a complete rewrite of the entire >> file: >> >> http://fossil.bradfords.org:8080/info/b08ec364c6aa7c2f >> >> But if I truncate the files (after about 137 lines) and only commit the >> partial files, it seems to handle it better: >> >> http://fossil.bradfords.org:8080/info/feebafd170f9399d >> > > My guess is this: > Fossil uses some heuristics to avoid the very large computation times a > large diff could bring. >
Indeed. The heuristic used in this case is probably https://www.fossil-scm.org/fossil/artifact/117b008502a5?ln=1005-1013 but in other cases https://www.fossil-scm.org/fossil/artifact/117b008502a5?ln=1080-1095 can cause the same effect on smaller change blocks. -- D. Richard Hipp d...@sqlite.org _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
