从CVS转换后，SVN会保存磁盘空间吗？

Question

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

Answer 1

服务器上的Subversion存储库使用与CVS类似的磁盘空间量。它可能会更多一些。但是，在客户端上，Subversion（至少在旧版本中）使用了相当多的磁盘空间。这是因为Subversion客户端保留了他们下载的每个源文件的原始副本。因此，如果你有50兆字节的源代码，你的Subversion工作目录大小将达到100兆字节。

然而，这确实反映了Subversion编写时代与CVS等程序的区别。

在过去，开发人员的桌面上可能只有20兆字节的驱动器，并且每个字节的可用空间都很宝贵。 CVS使用源文件的校验和来确定源文件是否已被修改。如果工作目录中的文件已更改，则它将具有不同的校验和。但是，这意味着如果您在文件上执行类似diff的操作，CVS将不得不与服务器通信以获取原始源文件的副本。

当Subversion出现时，磁盘空间以千兆字节为单位并且便宜。因此，有足够的空间在磁盘上安装原始源文件的第二个副本。现在，当您执行svn diff时，您没有生成任何网络流量或必须等待服务器响应。这大大加快了开发速度，设计Subversion的人认为权衡取舍是值得的。

最新版本的Subversion（版本1.7.x）具有与客户端上的工作目录不同的方式。我不知道它是如何工作的。但是，对我来说，磁盘空间是一个小问题。如果你需要更多，它足够便宜，可以获得更多。什么不便宜是你在开发中的时间和精力。开发越简单越快，就越好。

CVS在很长一段时间内没有更新。 Subversion被设计为替代品，与CVS取代RCS的方式大致相同。你应该选择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上。

Answer 2

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

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