我已经使用了一点 SVN 和 CVS，但需要为我将要开始的新项目选择一个。
是否有人广泛使用过这两种方法，请提供一些优点和缺点，以及他们认为哪个更好？最好的学习资源也将不胜感激。
这将是一个小项目，只有一两个开发人员开始。
【问题讨论】：
标签： svn version-control cvs
我都用过。没有可比性；你想要svn。使用 CVS 的唯一原因是因为您正在进入或接管一个不想改变现状的管理层的遗留系统。如果您开始一个新项目，那么从逻辑上讲 CVS 比 Subversion 更好几乎是不可能的。
如果您四处搜索，您应该会发现很多比较，以及使用 Subversion 而不是 CVS 的基本原理。 Subversion 相对于 CVS 的一些优势：
说了这么多，我建议你也探索一些分布式 VCS，比如 Bazaar、Mercurial 和 git。我个人在所有项目中都使用 git。
【讨论】：
"cheap" copying and branching 是什么？ Subversion 中的复制和分支如何更好（与 CVS 相比）？谢谢！
Subversion 在 CVS 上取得了一些实质性的胜利：
但是它有严重的缺点。到目前为止最大的是分支和标签不是 svn 中的一等公民，它们只是遵守约定的目录。除了失去真正分支和标记的一些好处（在其他 cmets 中提到）之外，它产生的最大问题是 if 很容易搞砸。
Subversion 使用约定而不是配置意味着您需要提前考虑您的存储库结构并确保每个人都遵守它。否则你会为子孙后代创造一个伤害世界，更不用说任何需要挖掘你的回购的工具了。
合并和镜像在 1.5 之前几乎不存在（很好的帮助）。 1.5 已采取措施解决这两个问题，但仍有改进的余地。在颠覆中合并仍然比它需要的要困难得多。
CVS 上的 SVN 几乎是轻而易举的事。但是，如果您没有考虑 DVCS 必须提供的功能（Git、Hg、Bzr），或者如果您的预算允许，那么您可能会失职，而如果您的预算允许的话，那么有一些商业工具具有良好的声誉（Accurev、Perforce）。
Subversion 可能是正确的选择，但您必须做好功课才能获得最佳效果。从红皮书开始http://svnbook.red-bean.com/
【讨论】：
虽然在大多数情况下我会选择 Subversion 而不是 CVS，但您应该知道 Subversion 缺少什么：
CVS 将标签和分支视为不同的事物；颠覆没有。这意味着构建在 Subversion 之上的第三方工具（例如具有源代码控制集成的 IDE）很难了解其中的区别。你通常需要做一些特殊的配置来告诉它你的标签和分支在哪里，你必须确保你的用户坚持特定的文件系统布局。
Subversion 无法查看文件并告诉您有人在什么时候创建了分支或标签。 CVSGraph 之类的工具可以使用此信息来绘制文件历史记录树。要使用 Subversion 做到这一点，您需要搜索所有分支/标签目录，我还没有看到任何工具可以很好地做到这一点。
根据我的经验，CVS 存在的时间更长，而且第三方工具更稳定。
【讨论】：
称我为老式，但我更喜欢 CVS 下的分支/标记模型。
在 CVS 中，分支和标签是不同的事物。标签是修订的标签。它们对于标记 PRODUCTION 标签以将文件同步到您的网络服务器等事情非常有用。您无需合并即可更新 PRODUCTION 文件——您只需移动标签即可。
分支与主文件位于相同的“命名空间”中——追踪特定文件的所有模块很容易。
在 SVN 中没有标签之类的东西。只有树枝。如果你想要标签，你需要创建一个分支并假装它是一个标签。分支基本上是文件的副本。上次我使用 SVN 进行分支/合并时，如果您希望将其重新合并在一起，则必须记录预分支文件的修订版（注意，我不是 SVN 专家，所以这可能已经改变）。
话虽如此，我认为 SVN 在其他方面都更好，您可能不应该使用 CVS 开始一个新项目。
【讨论】：
我怀疑你会得到很多答案。他们甚至可能都同意。
在这两个选择之间，我相信毫无疑问您应该使用 Subversion。 Subversion 被构建为“更好的 CVS”，因此，没有人再积极维护 CVS。 Subversion 能够重命名和移动文件而不会丢失历史记录，支持原子提交，具有更强大的存储库格式，具有更现代的访问方法，具有更好的第三方工具支持，等等。
【讨论】：
Subversion 就像“一个更好的 CVS”。它可以很好地处理移动文件和目录。它具有分支支持，尽管不如分布式 VCS。
您也可以考虑使用分布式 VCS，例如 git、bazaar 或 mercurial。
【讨论】：
通常是 Subversion .. 但是您应该注意资源问题。
当我在一家游戏公司工作时，我们有几个目录包含数百个小文件，而其他目录包含数百个 meg 文件。当我们从 CVS 切换到 Subversion 时，检查 repo 的速度从一小时减少到四五个小时。更新速度也慢了很多。
这几乎可以肯定是由于使用 http 或 ssh 传输文件数据，与本机 csv pserver 相比，但是由于通过 ssh 或 webdav 设置 svn 非常容易，人们往往不会考虑协议开销。但是，您可以使用本机 svn 协议，这应该可以缓解这个问题，我们没有在我的老公司进行测试。
另一个经常被忽略的问题是存储空间，我们发现 subversion 在本地使用的存储空间确实是 CVS 的数倍。我似乎记得它存储了 repo 数据的本地副本以加速差异，除非您在存储库中存储数 GB，否则这不会是一个大问题。
【讨论】：
我已经使用 subversion 3.5 年了，现在我搬到了另一家使用 CVS 进行源代码控制的公司。起初，两者之间没有太多区别，但谈到合并操作（这是我最关心的问题），我可以说 CVS 做得更好。 SVN 中的分支/标签的概念令人困惑，而在 CVS 中却非常清晰。在 CVS 中合并（在我的例子中是集成一个分支）也比在 SVN 中容易得多。 到目前为止，CVS 的弱点在我看来只有原子提交。否则，这将是一个不错的选择。
【讨论】：