On Wed, Jun 15, 2011 at 5:46 PM, Morten Kloster <morklo_at_gmail.com> wrote:
> On Wed, Jun 15, 2011 at 1:08 AM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
[]
>> Intuitively, I'd say: let's look into patience diff (or a variation
>> thereof), because it's already being used in several (D)VCS'es, so it
>> has already had a lot of exposure. But that's not really a strong
>> argument :-). Maybe another approach is easier to implement in
>> libsvn_diff, and yields equally good or even better results ... I
>> don't know.
>>
>
> Actually, patience diff doesn't solve this issue at all - once it has found
> an optimal match for the unique lines, it then performs regular minimal
> matches on the remaining sections, and it will be about as likely to
> generate spurious matches of blank lines as our current diff when
> there are large sections of non-matching code (or it can find spurious
> matches of unique lines, which can mess up things even worse).
Are you sure? Maybe there are different definitions of how patience
diff works (it seems to be rather undocumented :-)). I'm not really
into the details, but from what I've read on this thread on the git
mailinglist [1], I thought it worked recursively, more or less like
this:
(1) Find the unique lines, and perform an LCS on them.
(2) For each in-between section, again perform step (1) (finding
unique lines for this section, which may turn up new unique lines,
unique to this section).
Repeat this recursively, until there are no more unique lines in a
section. Then fall back to the regular diff algorithm (a "standard
minimal diff" on the remaining section).
--
Johan
[1] http://git.661346.n2.nabble.com/libxdiff-and-patience-diff-td1452272.html
Received on 2011-06-16 22:39:02 CEST