2011/6/15 Branko Čibej <br...@e-reka.si>: > On 15.06.2011 15:38, Johan Corveleyn wrote: >> 2011/6/15 Branko Čibej <br...@e-reka.si>: >>> On 15.06.2011 14:11, Johan Corveleyn wrote: >>>>> If you have a different definition of "mis-synchronizes", please explain. >>>> No, I don't mean a broken diff. The diff should at all times be >>>> *correct*. That was indeed never questioned. >>>> >>>> I mean something like the example Neels gave with his initial approach >>>> for avoid the mis-matching empty line problem. With the naive >>>> solution, he gave an example of where it's not nice: >>> [...] >>> >>> But when would the current "minimal" diff be preferable to the nicest, >>> albeit not minimal, diff we can produce? After all, the fix and/or >>> patience diff result is not only nicer to look at, it also gives better >>> results for blame, which is the other big diff consumer. >> Please define "nicest". > > The "nicest" is the one that looks most natural to a human. We will > never achieve that, but can certainly try.
I think we need something more machine-understandable / programmable than "most natural to a human" :-). >> Note that I gave an example where f.i. "patience diff" produces worse >> results IMHO than the "minimal diff" (right below Neels' example): >> >> [[[ >> file a >> >> aaaaaa >> aaaaaa >> bbbbbb >> bbbbbb >> cccccc >> cccccc >> abc >> >> file b >> >> abc >> aaaaaa >> aaaaaa >> bbbbbb >> bbbbbb >> cccccc >> cccccc >> >> Patience diff will give: >> >> -aaaaaa >> -aaaaaa >> -bbbbbb >> -bbbbbb >> -cccccc >> -cccccc >> abc >> +aaaaaa >> +aaaaaa >> +bbbbbb >> +bbbbbb >> +cccccc >> +cccccc >> >> Minimal diff will give: >> >> +abc >> aaaaaa >> aaaaaa >> bbbbbb >> bbbbbb >> cccccc >> cccccc >> -abc >> ]]] >> >> Which one is the nicest? > > Clearly, patience diff gets that heuristic wrong. :) I guess it depends. Maybe some humans are really focused on the 'abc'-line staying the same, and everything else being moved around it. > My point is this: If you start having options for specific diff > algorithm in "svn diff", are you going to extend them to "svn blame" and > "svn merge", too? Will different people get different blame results, > based on which algorithm is the default? Yes of course. Just like you can have different blame/merge results with --ignore-space-change and --ignore-eol-style. But gut feeling: if there is any sanity to both diff algorithms, blame will attribute the most significant lines to the same person/revision in both cases. That's just a guess though. > [...] > >> But I don't like the hand-waving discussion that it will always be >> superior, period. That's just not true. And it would be a big mistake, >> IMHO, to only support a heuristic diff. > > I'm not selling patience diff as generally superior. Clearly it has its > drawbacks, and there's no reason to assume those can't be fixed, whether > in the patience algorithm itself, or in an adaptation of that and other > ideas to "svn diff". I don't think there's a requirement to get from > "what we have now" to "best possible" in one iteration, or even in one > dot seven. > > Also please explain how "it would be a big mistake IMHO" is anything but > hand-waving. :) Yes, you're right. Sorry for the additional hand-waving :). -- Johan
