On 15.06.2011 15:38, Johan Corveleyn wrote:
> 2011/6/15 Branko Čibej <brane_at_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.
> 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. :)
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?
[...]
> 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. :)
-- Brane
Received on 2011-06-15 16:06:41 CEST