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