Re: [PATCH] Simplification/speed-up of libsvn_diff by eliminating idx

On Wed, Jun 1, 2011 at 10:04 AM, Philip Martin
<philip.martin_at_wandisco.com> wrote:
> Stefan Fuhrmann <eqfox_at_web.de> writes:
>
>>> Updated log message:
>>> [[[
>>> Simpler/faster LCS algorithm in libsvn_diff by elimination of idx.
>>>
>>> * subversion/libsvn_diff/lcs.c
>>>   (svn_diff__snake): Removed idx parameter (always 0)
>>>   (svn_diff__lcs): Removed idx variable (always 0) , let d have either
>>>    sign, and moved the origo of fp by d. New version no longer chooses
>>>    the shorter file as the "original", and can thus give different LCS's
>>>    depending on the order of the input files even when the files have
>>>    different lengths. Speed is ~15% faster for core lcs algorithm.
>>> ]]]
>> Committed as r1128857. I took the liberty to
>> weaken the speed-up claim.
>
> This commit fixed the spurious conflict on update in issue 3449, I
> suppose the chosen LCS is "better" in this particular case.  Are there
> likely to be cases where the chosen LCS is "worse" so that previously
> clean merges are now conflicts?
>
> See r1130036 for a 3449 regression test.

I was wondering about the exact same thing yesterday :). I suspected
that the sudden resolution to issue 3449 was related to this. The
chosen LCS is indeed better now, because it follows the same direction
for both comparisons involved in the update/merge (i.e. (Base, Mine)
and (Base, Theirs), whereas previously the LCS could be reversed based
on which side was shorter). See Morten's explanation (and my reply)
about this a couple of mails ago in this thread.

But I'm also unsure about your second question: are the cases where
there was previously a clean merge, and now a "spurious" conflict. I
suppose one could come up with an example, but I guess it would be
more up to interpretation whether or not there should be (or should
have been) a conflict. I have to think some more about this. Maybe
Morten has an idea?

Cheers,

-- 
Johan