CVS SVN VSS 使用对比.doc

CVS?SVN?VSS?使用对比(一)(2008-11-19 20:40:06) 如果用.net平台开发，VSS无疑首选，尽管它曾经有不经时事的诟病，现在发展的功能也蛮强的。如果有服务器linux系统，则CVS，SVN都可以选择。现在SVN大有取代CVS之势。然而很多古老的程序员还是对CVS情有独钟。 如下节选一些网上的对比说明，我作以综述。当然，真正要弄懂这些版本控制系统，还是要花费巨大工夫学习研究，不可能在baidu或者google几下就能完成的。 一、Subversion包含绝大部分CVS功能 Subversion 作为CVS 的重写版和改进版，其目标就是作为一个更好的版本控制软件，取代目前流行的CVS。Subversion 的主要开发人员都是业界知名的CVS 专家。Subversion支持绝大部分的CVS 功能/命令；Subversion 的命令风格和界面也与CVS 非常接近。当然，不同的地方正是对CVS 的改进。 二、全局性的版本编号 一个新的版本，并得到一个自增量的版本号N+1，该版本号并不针对某个特定的文件，而是全局性的、针对整个版本库的。因此，我们可以将Subversion 的版本库看作是一个文件系统或文件目录树的数组。 从技术的角度来说，在Subversion 中，“文件foo.c 的第5 版本”这个说法是错误的；正确的说法应该是：”文件foo.c 在版本库被修改了5 次，即执行5 次commit 后是什么样子？”。显然，在Subversion 中，版本库被修改5 次后foo.c 的内容，和被修改了6 次后foo.c 的内容很可能完全一样，因为版本库的第6 次修改很可能只修改了版本库的其他部分，而并没有对foo.c 的进行修改。相反，在CVS 中，文件foo.c 的第1.1 版本和第1.2 版本总是不同的。 Subversion 的全局性版本编号为Subversion 带来了诸多的优势：如对目录或文件执行拷贝，无论涉及多少文件，Subversion 不需要对单个文件依次执行拷贝命令，仅仅需要建立一个指向相应的全局版本号的一个指针即可。 三、目录的版本控制 CVS?只能对文件进行版本控制，不能对目录进行版本控制，因此CVS?没有任何关于文件“移动”（move）操作的概念。当人为进行文件移动操作时，CVS?只能注意到，一个文件在一个位置被删除了，而在一个新位置创建了另外一个文件。由于它不会连接两个操作，因此也很容易使文件历史轨迹丢失。设置?CVS?存储库时，必须非常谨慎地为每个文件选择准确的位置，因为在设置之后，几乎就要一直使用这个位置了。 同样由于CVS?不记录目录的版本历史，CVS?不支持对文件的“重命名”（rename），人为的对文件进行重命名会使得命名前后的文件失去历史联系，而记录历史本来是版本管理的主要目的。 还有，CVS?不支持对文件的“拷贝”（copy），人为的拷贝对CVS?而言，只能看到新的文件的增加，而不能记录拷贝源文件和目标文件之间的联系。 综上所述，缺乏对文件“移动”、“重命名”、“拷贝”的支持的根源在于CVS?不能记录目录的版本历史，而这些操作在当前的软件开发过程中经常发生，这正是Subversion被开发并取代CVS?的主要原因之一。 Subversion?将目录作为一类特殊的文件来处理（事实上，从文件系统的角度来看，目录确实是一类特殊的文件，当目录中的子目录/文件被删除、重命名、或新的子目录/文件被创建时，目录的内容将发生改变）。因此，Subversion?象记录普通文件的修改历史一样记录对目录的修改历史，当发生文件/目录的移动、重命名或拷贝操作时，Subversion?能够准确记录操作前后的历史联系。同样，象对文件的不同历史版本进行比较一样，Subversion支持对目录的不同历史版本的比较，清晰展现目录的变化历史。 四、原子性提交 从使用者的角度来看，CVS?和Subversion?都支持对多个文件修改的批量提交，但二者在实现方式上存在本质的区别。 CVS?采用线性、串行的批量提交，即依次地，一个接一个地执行提交，每成功提交一个文件，该文件的一个新的版本即被记录到版本库中，提交时用户提供的日志信息被重复地存储到每一个被修改的文件的版本历史中。 CVS?串行批量提交模式的弊端在于 －当任何原因造成批量操作的中断时（典型原因包括：网络中断、客户端死机等），版本库往往处于一个不一致的状态：原本应该全部入库的文件只有一部分入库，很有可能版本库中的最新版本不能顺利编译，更为严重的是，随着其他的用户执行cvs update?操作，该不一致性将迅速在开发团队中扩散，从而严重影响团队的开发效率，并存在质量隐患。另外，假如该批量提交的中断没有被及时发现，开发团队往往要花更多的时间进行软件调试和排错。