Question

cvs相对于svn来说有哪些好处与坏处？

cvs相对于svn来说有哪些好处与坏处？

Answer 1

cvs相对于svn来说的好处有：

1. cvs不必担心数据损失，可以手工修改RCS文件。

2. cvs对中文路径名的支持比较好。

3. cvs的本地文件与库的对应关系为：多对多。

4. cvs完全用户可见方式与客户端文件夹结构完全一致（cvs生成文件除外）。

5. cvs：管理员很难清楚的知道一个项目到底有多少个用户各用户的权限和密码是什么 只能用分组的方式管理用户而且密码和权限还是不清晰。

6. cvs：有read、write、creat、none这四种权限，任何人不能删除文件夹。

cvs相对于svn来说的坏处有：

1.cvs：不支持本地文件重命名提交， 不能删除文件夹。

2.CVS：网络传输速度比较慢。

3.CVS：只支持文本文件存储。

4.CVS中的“零或一”事务原则根本没有实现。

Answer 2

SVN与CVS优缺点对比：
1.对重命名、删除文件的支持
cvs：不支持本地文件重命名提交，删除分remove和erase两种前者把本地和库中文件都删除后者只是删除本地文件，不能删除文件夹
svn：支持文件重命名提交系统会提示删除旧文件，创建新文件，删除本地文件提交库中文件也被删除
2.对中文路径名的支持
cvs：支持的比较好
svn：要将权限控制文件保存为svn支持的UTF-8格式。
3.本地文件与库的对应关系
cvs：可以多对多
svn：一个库可以有多个工作目录但一个工作目录只能对应一个库虽然可以更改库位置但是要求很严格。下面我们看一下SVN与CVS优缺点比较中库中文件存放方式介绍。
4.库中文件存放方式
cvs：完全用户可见方式与客户端文件夹结构完全一致（cvs生成文件除外）
svn：与vss相似，看不到文件真正的内容
5.用户、权限管理
cvs：管理员很难清楚的知道一个项目到底有多少个用户各用户的权限和密码是什么只能用分组的方式管理用户而且密码和权限还是不清晰
svn：查看、修改配置文件即可
6.权限
cvs：有read、write、creat、none这四种权限，任何人不能删除文件夹（admin也只能跑到服务器上把相应文件夹残忍删除）
svn：只有read、write、none三种权限creat和delete权限好象和write是捆绑在一起的，关于两者备份的比较因为工作调动也没有继续研究。

Answer 3

打酱油

Answer 4

dd

Answer 5

一百度就有了啊，以下转载自http://blind.javaeye.com/blog/516527 ：

所有的文档都显示SVN可以取代CVS，同时SVN的问题和缺点都被隐藏了。不幸的是，我们并不认为SVN是CVS的替代品，尽管很多缺陷都被修改了。更有甚者，它甚至让人重回VSS。CVS和SVN的比较类似与比较C++和Java。很明显CVS和SVN都远比 SourceSafe强大的多，如同C++和Java比Basic强大的多。CVS代表了几乎代码控制系统的所有功能项，尽管有时他的实现并不很方便。 SVN,修正并添加了一些CVS并不拥有功能。例如，创建标志和分支dubious，你在编辑文件是其他人不会有任何通知。这有点象Java的发明者：他们认为你不需要指针他们就在Java里面取消了指针， Java里也没有操作符重载。
SVN并不是CVS的替代品。他只是个不同的系统，类似于CVS。它有些特有的功能，足以作为采用它的理由。这些功能使他更适合于开发环境，例如对 PowerBuilder。下面你可以找到两者的相对优势、劣势。我们假设余下的东西两者没有什么大差别。如果你对两者都举棋不定，我们建议试试两个系统，注意观察下面几个指标。你也可以到网上看看两者之间的讨论。
注意：这份评价表并不代表最终意见，两个系统仍然在开发之中。最后一次更新是在2005年七月（CVS NT 2.5.01和SVN 1.2)。

编号 对比项
CVS Vs SVN
===========================
1 存储类型格式
CVS是个基于RCS文件的版本控制系统。每个CVS文件都不过是普通的文件，加上一些额外信息。这些文件会简单的重复本地文件的树结构。因此，不必担心有什么数据损失，如果必要的话你可以手工修改RCS文件。
------------------------------
SVN是基于关系数据库的(BerkleyDB)或一系列二进制文件的(FS_FS)。一方面这解决了许多问题 (例如，并行读写共享文件)以及添加了许多新功能(例如运行时的事务特性。)。然而另一方面，数据存储由此变得不透明，或是说并不那么用户友好了。那就是为什么工具软件，对仓库 (数据库)变得那么重要了。
===========================
2 速度
CVS比较慢。
------------------------------
整体而言,由于架构实现的不同, SVN的确比CVS快很多。在网络上它只传输很少的信息并支持更多的离线模式的功能。但这也是有代价的。速度的代价就是巨大的存储（完全备份所有的工作文件）。
===========================
3 标志&分支 (!!!重要)
在我们看来，这些实现是适宜的。
------------------------------
SVN开发员自认为把采用标志和分支而抛弃了其他三件东西是件了不起的事。实际上这意味着他们把这个概念替换为在档案库内部复制文件或目录以便保存日志。这样一来，无论标志创建还是分支创建都只是仓库内部的文件复制了。在SVN的开发员看来，这是个很优雅的决策，这让生活变得如此简便。而我们看来，这丝毫没有什么值得骄傲之处。对分支而言，事情还不怎么糟糕，现在分支不过是在仓库内部的一个单独的目录而已了，不象早期还有些什么交错。对标志而言，事情就不那么妙了。你已经不能对代码加标志了，这个功能就这么没了。在某种程度上说，SVN全文件编号补足了这个缺陷， SVN里整个仓库都有版本号，但不是针对单个文件。当然，如果你认为一个符号标志比一个四位编码有效的话，我们业无话可说。
===========================
4 元数据
CVS只允许存储文件。
------------------------------
SVN允许一个文件有任意都的可命名属性。功能十分完全，但不知到有什么用。
===========================
5 文件类型
CVS最初是为文本文件存储而设计的。因此其他文件类型（二进制，统一码）文件的支持几乎没有，如需要的话则要有其他信息，并且客户端服务器端都要调整。
------------------------------
SVN会关心所有的文件类型，不需要你来手工操作。
===========================
6 滚回
CVS允许任意的滚回，在任意一个已递交的版本上，尽管着要花些时间（所有的文件都要分别处理）。
------------------------------
SVN不允许递交后滚回。我们建议把仓库里好的状态版本加到末尾，覆盖掉损坏的版本。而损坏的版本无论如何也是会存在数据库里的。（svn的滚回操作实际上是merge操作）
===========================
7 事务
CVS中的“零或一”事务原则根本没有实现。如果检入几个文件的话（加到服务器上），很有可能部分文件完成了，而另几个没有。做为一个潜规则，手工纠正这些并且对余下的文件 (而不是所有文件)一一重复检入。这样这些文件将在两阶段中被检入。但至今为止，因为这个功能缺少而导致的数据仓库损坏的案例还没有出现过。
------------------------------
SVN的确支持“零或一”事务原则，这是SVN的一大优势。
===========================
8 可用性
CVS可以用在你需要的地方，支持完善。
------------------------------
SVN并未广泛运用，一些支持项目仍然没有实现。
===========================

百度文库里也有，自己找找就有