0

嗨,我正在寻找 CVS 与 SVN 的直接比较。主要想知道 SVN 使用的磁盘空间比 CVS 中的磁盘空间少还是多?

4

2 回答 2

3

服务器上的 Subversion 存储库使用与 CVS 类似的磁盘空间量。可能会多一点。然而,在客户端上,Subversion(至少在旧版本中)使用了更多的磁盘空间。这是因为 Subversion 客户端保留了他们下载的每个源文件的原始副本。因此,如果您有 50 兆字节的源代码,那么您的 Subversion 工作目录的大小约为 100 兆字节。

但是,这确实反映了编写 Subversion 与 CVS 之类的程序的时代的不同。

在过去,开发人员的办公桌上可能只有 20 兆字节的驱动器,而每一字节的可用空间都是宝贵的。CVS 使用源文件的校验和来确定源文件是否被修改。如果您的工作目录中的文件被更改,它将具有不同的校验和。但是,这意味着如果您对文件进行了比较,CVS 将不得不与服务器对话以获取原始源文件的副本。

当 Subversion 出现时,磁盘空间以千兆字节为单位,而且很便宜。因此,您的磁盘上有足够的空间来保存原始源文件的第二个副本。现在,当您执行 a 时svn diff,您不会产生任何网络流量,也无需等待服务器响应。这极大地加快了开发速度,设计 Subversion 的人认为这种折衷是值得的。

最新版本的 Subversion(版本 1.7.x)在客户端上处理工作目录的方式有所不同。我对它的了解还不够,无法知道它是如何工作的。但是,对我来说,磁盘空间是一个小问题。如果您需要更多,它足够便宜以获得更多。不便宜的是您在开发中的时间和精力。开发越容易、越快,你的境况就越好。

CVS 很久很久没有更新了。Subversion 被设计为它的替代品,就像 RCS 被 CVS 替代一样。您应该选择 Subversion 而不是 CVS 的原因有很多。这并不是因为从事 CVS 工作的人是糟糕的开发人员。就是那些从事 Subversion 工作的人可以利用十多年的 CVS 经验来解决 CVS 存在的问题。

  • Subversion 有原子签入,而 CVS 没有。这本身应该是决定因素。在我们实践持续改进持续集成变更集的时代,签入是原子的很重要。如果我修改了 13 个程序来修复某个问题,而 CVS 只签入了其中的 12 个,那么生成的构建是错误的。不包括特定问题所需的所有更改。
  • Subversion 跟踪文件名的变化和移动。CVS 没有。
  • 在 Subversion 中更容易撤销更改。在 Subversion 中,我只需要知道版本号,我可以在一个命令中完成。在 CVS 中,我必须收集信息,并尝试找出答案。另外,Subversion 在还原更改方面要快得多。
  • Subversion 分支和标记更快。在许多 CVS 站点中,他们做了一些非常非常糟糕的程序实践,只是为了摆脱分支和标记。在 CVS 中可能需要 40 分钟或更长时间才能完成的事情在 Subversion 中需要一毫秒。
  • Subversion 更适用于持续集成系统。使用 CVS,CI 系统必须遍历整个 CVS 目录结构以查找更改。在 Subversion 中,CI 系统只需要查询项目的根目录最后一个修订版本是什么。
  • Subversion 中的分支和标记有其完整的历史。你知道是谁做的,什么时候做的,为什么做的。您可以查看是否有任何修改,谁做了这些,以及为什么。CVS 无法轻松获取此信息。

你可以谈论 Subversion vs. Git vs. Mercurial vs. Bazaar vs. Perforce,然后问谁更好。每个都是现代版本控制系统,每个都有自己的名声。

然而,Subversion 与 CVS 是不费吹灰之力的。CVS 是一个不再维护的版本控制系统,并且缺少现代版本控制系统中的关键功能。如果它是 CVS 和 Subversion 之间的选择,你把钱放在 Subversion 上。

于 2012-06-12T14:38:46.420 回答
0

在这种情况下,我将 cvs 转换为 svn,并在硬盘驱动器上找到了文件大小(当时它在我自己的笔记本电脑上)但在 svn 中比在 cvs 中小得多,但可能应用了一些压缩我不知道,但是网上的一切都说svn实际上会比cvs大。

所以我认为它对 2 的设置方式有点开放。

于 2012-08-09T08:24:58.137 回答