51

我已经使用了一些 SVN 和 CVS，但需要为我将要开始的新项目选择一个。

任何人都可以广泛使用这两种方法，请提供一些优点和缺点，他们认为哪个更好？最好的学习资源也将不胜感激。

这将是一个小项目，只有一两个开发人员开始。

4

8 回答 8

67

我都用过。没有可比性；你想要svn。使用 CVS 的唯一原因是因为您正在进入或接管一个不想改变现状的管理层的遗留系统。如果您开始一个新项目，那么从逻辑上讲 CVS 比 Subversion 更好几乎是不可能的。

如果你用谷歌搜索，你会发现很多比较，以及使用 Subversion 而不是 CVS 的基本原理。Subversion 相对于 CVS 的一些优势：

  • 可以干净地移动或重命名文件或目录
  • 原子提交
  • “便宜”的复制和分支
  • 提交是整个树上的变更集（不仅仅是单个文件的历史）

说了这么多，我建议你也探索一些分布式的 VCS，比如 Bazaar、Mercurial 和 git。我个人在所有项目中都使用 git。

于 2008-10-28T23:51:31.167 回答
22

Subversion 比 CVS 有一些实质性的胜利：

  1. 好的远程选项 http/https/svn vs pserver
  2. 原子提交
  3. 无处不在的工具支持
  4. 改名
  5. 目录版本控制

但是它有严重的缺点。到目前为止最大的是分支和标签不是 svn 中的一等公民，它们只是遵守约定的目录。除了失去真正分支和标记的一些好处（在其他评论中提到）之外，它产生的最大问题是 if 很容易搞砸。

Subversion 使用约定而不是配置意味着您需要提前考虑您的存储库结构并确保每个人都遵守它。否则你会为子孙后代创造一个伤害的世界，更不用说任何需要了解你的回购的工具了。

合并和镜像几乎不存在（很好的帮助）pre 1.5。1.5 已采取措施解决这两个问题，但仍有改进的余地。在颠覆中合并仍然比它需要的要困难得多。

SVN over CVS 几乎是轻而易举的事。但是，如果您没有考虑 DVCS 必须提供的功能（Git、Hg、Bzr），或者如果您的预算允许，那么您可能会失职，而如果您的预算允许的话，那么有一些商业工具具有良好的声誉（Accurev、Perforce）。

Subversion 可能是正确的选择，但您必须做好功课才能获得最佳结果。从红皮书开始http://svnbook.red-bean.com/

于 2008-10-29T01:51:12.860 回答
14

尽管在大多数情况下我会选择 Subversion 而不是 CVS，但您应该知道 Subversion 缺少什么：

  • CVS 将标签和分支视为不同的事物；颠覆没有。这意味着建立在 Subversion 之上的第三方工具（例如，集成了源代码控制的 IDE）很难知道其中的区别。你通常需要做一些特殊的配置来告诉它你的标签和分支在哪里，你必须确保你的用户坚持特定的文件系统布局。

  • Subversion 不能查看一个文件并告诉你某人在什么时候从它创建了一个分支或标签。CVSGraph 之类的工具可以使用此信息来绘制文件历史记录树。要使用 Subversion 做到这一点，您需要搜索所有分支/标签目录，而我还没有看到任何工具可以很好地做到这一点。

  • 根据我的经验，CVS 存在的时间更长，而且第三方工具更稳定。

于 2008-10-29T00:02:11.723 回答
9

称我为老式的，但我更喜欢 CVS 下的分支/标记模型。

在 CVS 中，分支和标签是不同的东西。标签是修订的标签。它们对于标记PRODUCTION标记以将文件同步到您的网络服务器等事情非常有用。您不必合并来更新PRODUCTION文件——您只需移动标签。

分支与主文件位于相同的“命名空间”中——很容易追踪特定文件的所有模块。

在 SVN 中没有标签之类的东西。只有树枝。如果你想要标签，你需要创建一个分支并假装它是一个标签。分支基本上是文件的副本。上次我使用 SVN 进行分支/合并时，如果您希望将其重新合并在一起，则必须记录预分支文件的修订版（注意，我不是 SVN 专家，所以这可能已经改变）。

话虽如此，我认为 SVN 在其他方面都更好，您可能不应该使用 CVS 开始一个新项目。

于 2008-10-29T00:01:52.583 回答
2

我怀疑你会得到很多答案。他们甚至可能都同意。

在这两个选择之间，我相信毫无疑问您应该使用 Subversion。Subversion 被构建为“更好的 CVS”，因此，没有人再积极维护 CVS。Subversion 能够重命名和移动文件而不会丢失历史记录，支持原子提交，具有更强大的存储库格式，具有更现代的访问方法，具有更好的第三方工具支持，等等。

于 2008-10-28T23:49:42.247 回答
1

Subversion 就像“一个更好的 CVS”。它可以很好地处理移动文件和目录。它具有分支支持，尽管不如分布式 VCS。

您也可以考虑使用分布式 VCS，例如 git、bazaar 或 mercurial。

编辑：这是一个类似问题的链接

于 2008-10-28T23:49:35.603 回答
1

一般来说 Subversion .. 但是你应该注意资源问题。

当我在一家游戏公司工作时，我们有几个目录包含数百个小文件，而其他目录包含数百个 meg 文件。当我们从 CVS 切换到 Subversion 时，检查 repo 的速度从一小时减少到四五个小时。更新速度也慢得多。

与原生 csv pserver 相比，这几乎可以肯定是由于使用 http 或 ssh 传输文件数据，但是由于通过 ssh 或 webdav 设置 svn 非常容易，人们往往不会考虑协议开销。但是，您可以使用本机 svn 协议，这应该可以缓解问题，我们没有在我的旧公司进行测试。

另一个经常被忽略的问题是存储空间，我们发现 subversion 在本地使用的存储空间确实是 CVS 的数倍。我似乎记得它存储了存储库数据的本地副本以加速差异，除非您在存储库中存储数 GB，否则这不会是一个大问题。

于 2009-03-02T23:45:23.650 回答
1

我已经使用 subversion 3.5 年了，现在我搬到了另一家使用 CVS 进行源代码控制的公司。起初，两者之间没有太多区别，但谈到合并操作（这是我最关心的问题），我可以说 CVS 做得更好。SVN 中的分支/标签的概念令人困惑，而在 CVS 中却非常清晰。在 CVS 中合并（在我的例子中是集成一个分支）也比在 SVN 中容易得多。到目前为止，CVS 的弱点在我看来只有原子提交。否则，这将是一个不错的选择。

于 2012-08-16T04:27:25.863 回答