Subversion vs CVS [已关闭]

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

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

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

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

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

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

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

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

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

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

在 CVS 中，分支和标签是不同的东西。标记是修订版的标签。它们对于标记 PRODUCTION 标记以同步到您的 Web 服务器等操作非常有用。您不必合并即可更新 PRODUCTION 文件，只需移动标签即可。

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

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

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

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

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

• Subversion 无法查看文件并告诉您某人在何时从中创建了分支或标签。像 CVSGraph 这样的工具可以使用这些信息来绘制文件历史记录树。要使用 Subversion 做到这一点，您需要搜索所有分支/标签目录，而我还没有看到任何工具可以很好地做到这一点。

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

Subversion 比 CVS 取得了一些实质性的胜利：

1. 良好的远程选项 HTTP/HTTPS/SVN 与 pserver
2. 原子提交
3. 无处不在的工具支持
4. 重命名
5. 目录版本控制

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

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

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

SVN over CVS 几乎是轻而易举的事。但是，如果不考虑 DVCS 必须提供什么（Git、Hg、Bzr），或者如果您的预算允许，则有信誉良好的商业工具（Accurev、Perforce），那就太失职了。

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

一般是颠覆..但是，您应该注意资源问题。

当我在一家游戏公司工作时，我们有几个目录包含数百个小文件，而其他目录则包含几百个 meg 文件。当我们从 CVS 切换到 Subversion 时，签出 repo 的速度从 1 小时下降到 4 或 5 小时。更新速度也大大减慢。

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

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

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