Ittay,
checking a file as-is should have been the default, and changing its
line endings should have been a nice feature to enable.
I disagree (as obviously have everyone who worked on the code before
today).
What you suggest is unworkable. Let me explain by way of example: on
OS/400 an ASCII stream file with LF line endings is completely unusable
by any text editor on (unless you port GNU VI or something), all the
native OS/400 editors use the native OS/400 Source Physical Files text
format - fixed length records. So if you want to checkout a text file
and it be editable by a text editor then the tool is best off formatting
it for the native platform.
and what if i don't intend to edit it in that platform?
So let's take the flipside to your suggestion: 'binary files (-kb)
should be mergable' to which the answer is - the cvs tool would have no
way to understand how to merge them. Now your argument is that it's not
'really' a binary file it is 'really' text - but 'text' by what
definition - the definition of 'text' on windows is that lines are
terminated by a CRLF pair so all the native CRT functions assume that.
The merge routines use the CRT and so the file must obey the line ending
rules of the CRT.
So back to the beginning - if CVS cannot treat the file as 'text' -
including supporting the platform dependant line format (fixed length
records, LF terminated, CRLF terminated, CR terminated etc) then CVS
cannot merge the files so it must be treated as binary preserving /
non-mergable.
Regards,
Arthur Barrett