[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Madan U Sreenivasan <madan_at_collab.net>
Date: 2006-07-08 07:21:17 CEST

On Fri, 07 Jul 2006 23:35:28 +0530, Lieven Govaerts <lgo@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.


> 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

> 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.

Madan U S

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jul 8 01:51:52 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.