Paul, > If you check the file out on the platform for which the text is > ultimately destined, you would not have this problem. Check it out > on Windows, it works on Windows. Check it out on Linux, it works on > Linux. Under no circumstances, using CVS or not, should you expect > text files on one platform to work on the other when simply mounted > or copied bit-for-bit.
I think part of the problem here is the tendancy for some people (mostly programmers) to treat windows as unix (or put another way - to fail to obey windows rules on windows). Several examples of this are: * IDEs on windows that read LF terminated text files * Compilers on windows that read LF terminated text files So people using windows become accustomed to the 'fact' that windows understands LF terminated text files. Along comes a program like CVS that does not try and mix its metaphores and people claim CVS is broken. No programmer or user of HPUX would ever accept any program running on HPUX that opened a text file and 'auto-discovered' it's line endings and presented it perfectly - if it has LF line endings it works and anything else will show up as rubbish. Windows (being more popular?) has become its own worst enemy - by becoming more 'usable' it's also broken its own rules. One solution is for tools like CVS to treat windows text files the same way - 'intelligently' determine the line type rather than believe the 'windows rule book' that windows text files have CRLF. This of course means throwing away the C RunTime (CRT) which will then break easy portability (which is generally considered important for the CVS project). In CVSNT we've experimented with this approach - basically trying to use auto detected mime types instead of hard and fast rules - generally with pretty poor results always forcing us back to defined line endings - with -k+L/-k+M/-k+D as the only viable alternative. In the latest CVSNT 2.5.04 we've attempted to be more aggressive at 'auto fixing' broken line endings on checkin - but since this release is not stable yet we've limited feedback on how this performs in the real world. Regards, Arthur Barrett
