Mailing-List: contact users-help@subversion.apache.org; run by ezmlm
Precedence: bulk
From: "Bert Huijben" <bert@qqmail.nl>
To: "'Daniel Shahaf'" <d.s@daniel.shahaf.name>,
	"'Michal Matyl'" <Michal.Matyl@zf.com>
Cc: <users@subversion.apache.org>
References: 
 <BLUPR0601MB738480182C1642DE3B2EAA385A80@BLUPR0601MB738.namprd06.prod.outlook.com>
 <20160214143442.GA5664@tarsus.local2>
In-Reply-To: <20160214143442.GA5664@tarsus.local2>
Subject: RE: (unknown)
Date: Mon, 22 Feb 2016 13:20:55 +0100
Message-ID: <3f4901d16d6b$7c9a72c0$75cf5840$@qqmail.nl>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQI31TEzXrAOJ+yyOUpzUQTJ5+TV1gHFo0qXnlz8uvA=
Content-Language: nl


> -----Original Message-----
> From: Daniel Shahaf [mailto:d.s@daniel.shahaf.name]
> Sent: zondag 14 februari 2016 15:35
> To: Michal Matyl <Michal.Matyl@zf.com>
> Cc: users@subversion.apache.org
> Subject: Re: (unknown)
>=20
> Michal Matyl wrote on Thu, Feb 11, 2016 at 10:19:02 +0000:
> > The example is about a simple branch merging with default settings =
and
> > a classic conflict situation, no fancy features or complex
> > trunk-to-branch back merging, so I belive simple prose description =
of
> > the problem is enough.
>=20
> The prose did not suffice: I would not have understood the problem
> without the attachment.  The preferred way to describe a bug is by
> a script that reproduces it.
>=20
> For future reference, we provide template scripts at:
> https://subversion.apache.org/docs/community-
> guide/issues.html#reporting-bugs
> (fourth paragraph)
>=20
> > First developer creates branch-01 and inserts few lines into =
existing
> > file. Another developer creates branch-02 and makes exactly the same
> > changes as first developer, i.e. inserts the same lines with the =
same
> > content. The only difference in the second's developer branch is
> > whitespace change (space/tab doesn't matter) in a line preceding
> > inserted lines.
> >
>=20
> You are describing a merge where
>=20
> * The difference between the OLD and MINE is:
>=20
>     Index: branches/branch-01/test_file.txt
>=20
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D
> =3D=3D=3D=3D=3D=3D=3D=3D=3D
>     --- branches/branch-01/test_file.txt    (revision 3)
>     +++ branches/branch-01/test_file.txt    (revision 4)
>     @@ -1,6 +1,9 @@
>      A
>      B
>      C
>     +D
>     +E
>     +F
>      J
>      K
>      L
>     \ No newline at end of file
>=20
> * The difference between OLD and THEIRS is:
>=20
>     Index: branches/branch-02/test_file.txt
>=20
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D
> =3D=3D=3D=3D=3D=3D=3D=3D=3D
>     --- branches/branch-02/test_file.txt    (revision 6)
>     +++ branches/branch-02/test_file.txt    (revision 7)
>     @@ -1,6 +1,9 @@
>      A
>      B
>     -C
>     + C
>     +D
>     +E
>     +F
>      J
>      K
>      L
>     \ No newline at end of file
>=20
> * There are no local mods.
>=20
> That merge results in:
>=20
>     Index: trunk/test_file.txt
>=20
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D
> =3D=3D=3D=3D=3D=3D=3D=3D=3D
>     --- trunk/test_file.txt (revision 7)
>     +++ trunk/test_file.txt (revision 8)
>     @@ -1,9 +1,12 @@
>      A
>      B
>     -C
>     + C
>      D
>      E
>      F
>     +D
>     +E
>     +F
>      J
>      K
>      L
>     \ No newline at end of file
>=20
> Yes, I also think that is a bug: a text conflict should have been
> flagged.

I just reviewed most of the code that is responsible for this =
behavior... and I have to conclude it works 'as designed'.

1) We determine the changes on both sides.
* On one side we see a replacement of line 'C', by a different set of =
tokens.
* And on the other side we see an insertion of a set of tokens after =
'C'.
(This code is in subversion/diff/lcs.c)

2) Then we combine the changes of both sides.
* We can apply the first change as there are no overlapping regions
* We can apply the second change as there no overlapping regions
(This code is in subversion/diff/diff3.c)

In our very abstract implementation things work as intended... so now we =
have to determine how we want to fix things. -> back to design phase.


I have a working patch that determines that these changes touch each =
other and then marks them as conflict, but that still doesn't produce =
the kind of conflict that you would really want here. And I'm not sure

In the optimal case we would flag one conflict containing both changes =
*as one*, but that will take more work.


Note that the 'whitespace' (noted in original report) is completely =
unrelated to this issue. Our diff code works with tokens, while the =
whitespace is handled in the tokenizer. I can easily reproduce this =
issue without any whitespace changes.

	Bert