svn trunk incorrectly calculates conflict when eol-style propchanges are involved.

[Lieven Govaerts <lg...@mobsol.be>]

Hi, 


I started working on a python test to validate the correct behaviour of
dionisos/eh's changes in r20387 (Copy the wc file using the translation
system, to ensure correct line endings). I can't get the test to pass, but I
think it's a problem with the code and not with the test. Attached is the
patch for the python test. 

Here a verbose description of the test, if you understand the python test,
you can skip this part and move on directly to Opinion.

Test:
=====
Say we have working copies A and B. Both start at the same revision, with a
copy of file mu, no eol-style property set, eol used = LF.

The text-base copy of mu looks like this
This is the file 'mu'.[LF]

In working copy A, we change my by adding an extra line:
This is the file 'mu'.[LF]
This is an extra line.[LF]

In working copy B, we start from the same base file, but set the eol-style
property to [CRLF] and also added an extra line:

The text-base copy of mu in wc B looks like this:
This is the file 'mu'.[CRLF]

The working copy of mu is changed, an extra line was added:
This is the file 'mu'.[CRLF]
This is a conflict line.[CRLF]

We commit working copy B. 

If we now update working copy A, svn on trunk will behave exactly as Erik
told me on IRC yesterday. File mu will be detranslated (nothing changes
because no eol-style property set), the conflict with the new text-base will
be calculated and then the resulting files will be translated with the
incoming eol-style property CRLF.

The resulting conflict file will look like this:
<<<<<<< .mine[CRLF]
This is the file 'mu'.[CRLF]
This is an extra line.[CRLF]
=======[CRLF]
This is the file 'mu'.[CRLF]
This is a conflict line.[CRLF]
>>>>>>> .r6[CRLF]

Opinion:
========
While the resulting conflict is technically correct, I think we can do
better here. The line 'This is the file 'mu'.[CRLF]' is only inside the
conflict markers because of the eol's not matching in the text-base. The
current behaviour would be correct if the text-base files are normalized
(all LF, whatever the eol-style property), but that's not what we do now.

What should happen (again, in my opinion) is that an incoming eol-style
propchange should be applied directly to the new text-base before
calculating the conflict. Now that I think about it, I find it strange that
it doesn't happen now.

thanks for any input,

Lieven.

Re: svn trunk incorrectly calculates conflict when eol-style propchanges are involved.

[Madan U Sreenivasan <ma...@collab.net>]

On Fri, 07 Jul 2006 23:35:28 +0530, Lieven Govaerts <lg...@mobsol.be> wrote:

> Hi,
>
>
> I started working on a python test to validate the correct behaviour of
> dionisos/eh's changes in r20387 (Copy the wc file using the translation
> system, to ensure correct line endings). I can't get the test to pass,  
> but I
> think it's a problem with the code and not with the test. Attached is the
> patch for the python test.

[snip]

> Opinion:
> ========
> While the resulting conflict is technically correct, I think we can do
> better here. The line 'This is the file 'mu'.[CRLF]' is only inside the
> conflict markers because of the eol's not matching in the text-base. The
> current behaviour would be correct if the text-base files are normalized
> (all LF, whatever the eol-style property), but that's not what we do now.

I agree.

> What should happen (again, in my opinion) is that an incoming eol-style
> propchange should be applied directly to the new text-base before
> calculating the conflict.

I have two questions here.

1) By 'applied directly' you mean, making the CRLF comparison loose to  
return TRUE for the following comparisons and the deductive cases, right?
     CRLF == CR
     CR   == LR


2) When we apply wc B's line-ending style on the text-base, will this also  
get committed to the repository? (am assuming so for the following  
discussion)

> Now that I think about it, I find it strange that
> it doesn't happen now.

I can imagine one situation when this could go wrong. In embedded  
application development, the line ending of the on-board-os could be  
different from the one on which code is actually edited (host) machine.  
Now, if we force the line-ending of the last commit into the file, some  
tools on the board might even error out because of the wrong line-endings.

That said, am not totally against your idea. Just think we need some  
caution here.

Regards,
Madan U S
www.symonds.net/~madan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org