Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: domain of jcorvel@gmail.com designates
 209.85.210.171 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :cc:content-type:content-transfer-encoding;
        b=s9O9uYqAaAOheSV7Qt/jmUA1LJ13pGeN5O33uHdQQyGiV0gTDT/DV5lqnPkBmDuK0H
         ruZbS4jS3AZW22CIt94xqA4t2zJXYmtnQJv9798mxZIm7krRRT5SS7o++BTEiWlyaRzQ
         dFPIr9hdXhSGBFsJCV3fWVFMUP8VxzWafq4/k=
MIME-Version: 1.0
In-Reply-To: <87vcwqm0z8.fsf@stat.home.lan>
References: 
 <2AD5BED2527E354DB77EB7C09A081E451824000A@fe20099s.ecn.etasgroup.com>
 <BANLkTi=f3BK0-a4sEjx2LPdv4aru1MZFnA@mail.gmail.com>
 <1306501985.1991.1918.camel@edith>
 <BANLkTikZWtCzsQoMprH5G2=z3JbWZhB-jw@mail.gmail.com>
 <4DE22DA4.8090805@web.de>
 <87vcwqm0z8.fsf@stat.home.lan>
From: Johan Corveleyn <jcorvel@gmail.com>
Date: Wed, 1 Jun 2011 10:28:15 +0200
Message-ID: <BANLkTik-3NR2vHEL99rAhOo0czAZWs17AQ@mail.gmail.com>
Subject: Re: [PATCH] Simplification/speed-up of libsvn_diff by eliminating idx
To: Philip Martin <philip.martin@wandisco.com>
Cc: Stefan Fuhrmann <eqfox@web.de>, dev@subversion.apache.org,
 morklo@gmail.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 1, 2011 at 10:04 AM, Philip Martin
<philip.martin@wandisco.com> wrote:
> Stefan Fuhrmann <eqfox@web.de> writes:
>
>>> Updated log message:
>>> [[[
>>> Simpler/faster LCS algorithm in libsvn_diff by elimination of idx.
>>>
>>> * subversion/libsvn_diff/lcs.c
>>> =A0 (svn_diff__snake): Removed idx parameter (always 0)
>>> =A0 (svn_diff__lcs): Removed idx variable (always 0) , let d have eithe=
r
>>> =A0 =A0sign, and moved the origo of fp by d. New version no longer choo=
ses
>>> =A0 =A0the shorter file as the "original", and can thus give different =
LCS's
>>> =A0 =A0depending on the order of the input files even when the files ha=
ve
>>> =A0 =A0different 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. =A0Are 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,
--=20
Johan