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 > > Notice that one can scroll to the right and see additional changes on > most lines. > > What's going on here? My guess is this: Fossil uses some heuristics to avoid the very large computation times a large diff could bring. In the first example, the files are too changed for the heuristic part to find all the equal lines, and too big for it to allow going into the exact algorithm. This leads to a rather large change block (758 vs 764 lines), which is too large for the algorithm that matches lines within a block, and thus it is displayed as one big change. /Peter
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
