On Fri, 07 Jul 2006 23:35:28 +0530, Lieven Govaerts <firstname.lastname@example.org> wrote:
> 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.
> 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.
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
Madan U S
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Sat Jul 8 01:51:52 2006