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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 7 20:06:08 2006