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.
[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
Received on Sat Jul 8 01:51:52 2006