subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bert Huijben" <b...@qqmail.nl>
Subject RE: (unknown)
Date Mon, 22 Feb 2016 12:20:55 GMT


> -----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)
> 
> 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.
> 
> 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.
> 
> For future reference, we provide template scripts at:
> https://subversion.apache.org/docs/community-
> guide/issues.html#reporting-bugs
> (fourth paragraph)
> 
> > 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.
> >
> 
> You are describing a merge where
> 
> * The difference between the OLD and MINE is:
> 
>     Index: branches/branch-01/test_file.txt
> 
> ==========================================================
> =========
>     --- 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
> 
> * The difference between OLD and THEIRS is:
> 
>     Index: branches/branch-02/test_file.txt
> 
> ==========================================================
> =========
>     --- 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
> 
> * There are no local mods.
> 
> That merge results in:
> 
>     Index: trunk/test_file.txt
> 
> ==========================================================
> =========
>     --- 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
> 
> 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


Mime
View raw message