这个附录可以作为CVS用户开始使用Subversion的指南，实质上就是鸟瞰这两个系统之间的区别列表，在每一小节，我们会尽可能提供相关章节的引用。 尽管Subversion的目标是接管当前和未来的CVS用户基础，需要一些新的特性设计来修正一些CVS不好的行为习惯，这意味着，作为一个CVS用户，你或许需要打破习惯—忘记一些奇怪的习惯来作为开始。 在CVS中，修订版本号是每文件的，这是因为CVS使用RCS文件保存数据，每个文件都在版本库有一个对应的RCS文件，版本库几乎就是根据项目树的结构创建。 在Subversion，版本库看起来像是一个单独的文件系统，每次提交导致一个新的文件系统；本质上，版本库是一堆树，每棵树都有一个单独的修订版本号。当有人谈论修订版本54时，他们是在讨论一个特定的树（并且间接来说，文件系统在提交54次之后的样子）。 技术上讲，谈论文件foo.c的修订版本5是不正确的，相反，一个人会说foo.c在修订版本5出现。同样，我们在假定文件的进展时也要小心，在CVS，文件foo.c的修订版本5和6一定是不同的，在Subversion，foo.c可能在修订版本5和6之间没有改变。 更多细节见. Subversion会记录目录树的结构，不仅仅是文件的内容。这是编写Subversion替代CVS最重要的一个原因。 以下是对你这意味着什么的说明，作为一个前CVS用户： svn add和svn delete现在也工作在目录上了，就像在文件上一样，还有svn copy和svn move也一样。然而，这些命令不会导致版本库即时的变化，相反，工作的项目只是预定要添加和删除，在运行svn commit之前没有版本库的修改。 目录不再是哑容器了；它们也有文件一样的修订版本号。（更准确一点，谈论修订版本5的目录 foo/是正确的。） 让我们再讨论一下最后一点，目录版本化是一个困难的问题；因为我们希望允许混合修订版本的工作拷贝，有一些防止我们滥用这个模型的限制。 从理论观点，我们定义目录foo的修订版本5意味着一组目录条目和属性。现在假定我们从foo开始添加和删除文件，然后提交。如果说我们还有foo的修订版本5就是一个谎言。然而，如果说我们在提交之后增加了一位foo的修订版本号码，这也是一个谎言；foo还有一些修改我们没有得到，因为我们还没有更新。 Subversion通过在.svn区域偷偷的纪录添加和删除来处理这些问题，当你最后运行svn update，所有的账目会到版本库结算，并且目录的新修订版本号会正确设置。因此，只有在更新之后才可以真正安全地说我们有了一个完美的修订版本目录。在大多数时候，你的工作拷贝会保存不完美的目录修订版本。 同样的，如果你尝试提交目录的属性修改会有一个问题，通常情况下，提交应该会提高工作目录的本地修订版本号，但是再一次，这还是一个谎言，因为这个目录还没有添加和删除发生，因为还没有更新发生。因此，在你的目录不是最新的时候不允许你提交属性修改。 关于目录版本的更多讨论见。 近些年来，磁盘空间变得异常便宜和丰富，但是网络带宽还没有，因此Subversion工作拷贝为紧缺资源进行了优化。 .svn管理目录维护者与CVS同样的功能，除了它还保存了只读的文件原始拷贝，这允许你做许多离线操作： svn status 显示你所做的本地修改（见） svn diff 显示修改的详细信息（见see ） svn revert 删除你的本地修改（见） 另外，原始文件的缓存允许Subversion客户端在提交时只提交区别，这是CVS做不到的。 列表中最后一个子命令是新的；它不仅仅删除本地修改，也会取消如增加和删除的预定操作，这是恢复文件推荐的方式；运行rm file; svn update还可以工作，但是这样侮辱了更新操作的作用，而且，我们在这个主题… 在Subversion，我们已经设法抹去cvs status和cvs update之间的混乱。 cvs status命令有两个目的：第一，显示用户在工作拷贝的所有本地修改，第二，显示给用户哪些文件是最新的。很不幸，因为CVS难以阅读的状态输出，许多CVS用户并没有充分利用这个命令的好处。相反，他们慢慢习惯运行cvs update或cvs -n update来快速查看区别，如果用户忘记使用-n选项，副作用就是将还没有准备好处理的版本库修改合并到工作拷贝。 对于Subversion，我们通过修改svn status的输出使之同时满足阅读和解析的需要来努力消除这种混乱，同样，svn update只会打印将要更新的文件信息，而不是本地修改。 svn status打印所有本地修改的文件，缺省情况下，不会联系版本库，然而这个命令接受一些选项，如下是一些最常用的： svn status会打印所有本地修改的文件，缺省条件下，不会访问版本库，然而这个子命令可以接受一些选项，下面是最常用的一些： -u 访问版本库检测并显示过期的信息。 -v 显示所有版本控制下的文件。 -N 非递归方式运行（不会访问子目录）。 status命令有两种输出格式，缺省是短格式，本地修改像这样： $ svn status M foo.c M bar/baz.c 如果你指定--show-updates（-u）选项，就会使用较长的格式输出： $ svn status -u M 1047 foo.c * 1045 faces.html * bloo.png M 1050 bar/baz.c Status against revision: 1066 在这个例子里，出现了两列，第二列的星号表示了文件或目录是否过期，第三列显示了工作拷贝修订版本号，在上面的例子里，星号表示如果进行更新，faces.html会被合并，而bloo.png则是版本库新加的文件。（bloo.png前面的修订版本号为空表示了这个文件在工作拷贝已经不存在了。） 最后，下面是大多数你可能看到的最普通状态码的总结： A Resource is scheduled for Addition D Resource is scheduled for Deletion M Resource has local Modifications C Resource has Conflicts (changes have not been completely merged between the repository and working copy version) X Resource is eXternal to this working copy (may come from another repository). See ? Resource is not under version control ! Resource is missing or incomplete (removed by another tool than Subversion) 关于svn status的详细讨论，见。 svn update会更新你的工作拷贝，只打印这次更新的文件。 Subversion将CVS的P和U合并为U，当合并或冲突发生时，Subversion会简单的打印G或C，而不是大段相关内容。 关于svn update的详细讨论，见。 Subversion不区分文件系统空间和分支空间；分支和标签都是普通的文件系统目录，这恐怕是CVS用户需要逾越的最大心理障碍，所有信息在。 因为Subversion把分支和标签看作普通目录看待，一直要记住检出项目的trunk（http://svn.example.com/repos/calc/trunk/），而不是项目本身的（http://svn.example.com/repos/calc/）。如果你错误的检出了项目本身，你会紧张的发现你的项目拷贝包含了所有的分支和标签。如果在检出完成之前没有消耗完磁盘空间的话。 Subversion的一个新特性就是你可以对文件和目录任意附加元数据（或者是属性），属性是关联在工作拷贝文件或目录的任意名称/值对。 为了设置或得到一个属性名称，使用svn propset和svn propget子命令，列出对象所有的属性，使用svn proplist。 更多信息见。 CVS使用内联冲突标志来标记冲突，并且在更新时打印C。历史上讲，这导致了许多问题，因为CVS做得还不够。许多用户在它们快速闪过终端时忘记（或没有看到）C，即使出现了冲突标记，他们也经常忘记，然后提交了带有冲突标记的文件。 Subversion通过让冲突更明显来解决这个问题，它记住一个文件是处于冲突状态，在你运行svn resolved之前不会允许你提交修改，详情见。 在大多数情况下，Subversion比CVS更好的处理二进制文件，因为CVS使用RCS，它只可以存储二进制文件的完整拷贝，但是，Subversion使用二进制区别算法来表示文件的区别，而不管文件是文本文件还是二进制文件。这意味着所有的文件是以微分的（压缩的）形式存放在版本库。 CVS用户需要使用-kb选项来标记二进制文件，防止数据的混淆（因为关键字解释和行结束转化），他们有时候会忘记这样做。 Subversion使用更加异想天开的方法—第一，如果你不明确的告诉它（详情见和）这样做，它不会做任何关键字或行结束转化的操作，缺省情况下Subversion会把所有的数据看作字节串，所有的储存在版本库的文件都处于未转化的状态。 第二，Subversion维护了一个内部的概念来区别一个文件是文本还是二进制文件，但这个概念只在工作拷贝非常重要，在svn update，Subversion会对本地修改的文本文件执行上下文的合并，但是对二进制文件不会。 为了检测一个上下文的合并是可能的，Subversion检测svn:mime-type属性，如果没有svn:mime-type属性，或者这个属性是文本的（例如text/*），Subversion会假定它是文本的，否则Subversion认为它是二进制文件。Subversion也会在svn import和svn add命令时通过运行一个二进制检测算法来帮助用户。这些命令会做出很好的猜测，然后（如果可能）设置添加文件的svn:mime-type属性。（如果Subversion猜测错误，用户可以删除或手工编辑这个属性。） 不像CVS，Subversion工作拷贝会意识到它检出了一个模块，这意味着如果有人修改了模块的定义（例如添加和删除组件），然后一个对svn update的调用会适当的更新工作拷贝，添加或删除组件。 Subversion定义了模块作为一个目录属性的目录列表：见。 通过CVS的pserver，你需要在读写操作之前登陆到服务器—即使是匿名操作。Subversion版本库使用Apache的httpd或svnserve作为服务器，你不需要开始时提供认证凭证—如果一个操作需要认证，服务器会要求你的凭证（不管这凭证是用户名与密码，客户证书还是两个都有）。所以如果你的工作拷贝是全局可读的，在所有的读操作中不需要任何认证。 相对于CVS，Subversion会一直在磁盘（在你的~/.subversion/auth/目录）缓存凭证，除非你通过--no-auth-cache选项告诉它不这样做。 这个行为也有例外，当使用SSH管道的svnserve服务器时，使用svn+ssh://的URL模式这种情况下，ssh会在通道刚开始时无条件的要求认证。 或许让CVS用户熟悉Subversion最好的办法就是让他们的项目继续在新系统下工作，这可以简单得通过平淡的把CVS版本库的导出数据导入到Subversion完成，或者是更加完全的方案，不仅仅包括最新数据快照，还包括所有的历史，从一个系统到另一个系统。这是一个非常困难的问题，包括推导保持原子性的修改集，转化两个系统完全不同的分支政策。但是我们还是有许多工具声称至少部分具备了的转化已存在的CVS版本库为Subversion版本库的能力。 其中一个工具是cvs2svn（），是一个Python脚本，最初是Subversion自己的开发社区的成员编写的。其他的如Lev Serebryakov的RefineCVS（）。这些工具具备不同程度的完成性，也许会具备完全不同的处理CVS历史的方法。无论你决定使用哪个工具，确定要执行尽可能多的验证来确定你可以接受转化结果—毕竟，你曾经努力创建这些历史！ 关于最新的转化工具链接列表，可以访问Subversion的网站（）。