cvs与svn的二进制处理与行结束转化

最近发现有种情况可以造成cvs上checkout出来的文件错误：
1,win32下编辑文本格式文件并保存
2,,,,传到linux机器上commit进cvs
3,回到win32机器上checkout,用vim打开所有行尾都多了一个^M
这个文件如果是makefile将不被make所接受（javac可以忽略这个错误）
而subversion没有这样的问题。

问题出在cvs对于文件的处理方式上
cvs默认所有文件为文本格式，如果是二进制文件需要用-kb指定
作为文本文件处理时cvs会将换行解释成自己的lineseparator
win32文件的换行符/r/n，放到linux上commit，cvs认为linux的换行符是/n，于是将/n转换成lineseparator储存，这样再从win32系统上checkout，cvs又将lineseparator解释成/r/n于是行尾全部变成/r/r/n

而subversion先进的地方在于
1,采用了一种二进制文件判断算法，自动判别是否二进制文件
2,基于1的算法，并不在传输与储存时改变文件，而是在属性文件中保存文件的状态。
在.svn-base文件中你可能会发现svn:mime-type这样一个属性，这就表示这是一个binary文件。而在存储的时候所有文件都是用byte code方式压缩存储。因此也就没有行尾处理的问题。