偏好SVS或Git的原因

Question

我刚刚发现了一个仍然使用CVS的开源项目.我想知道现在还有什么理由比CVN或Git更喜欢CVS.(我不认为懒得迁移作为答案!;-))

CVS有其他两个缺乏的东西吗？比如说,支持$ OS或$ fancy_tool？

在" 使用SVN而不是CVS有什么好处？"有详细解释为什么不使用CVS.但我想反过来问问.CVS不可能都是坏事.或者是吗？

Answer 1

我仍然使用CVS作为我个人的一些东西.

与Git不同,您可以轻松地仅检出存储库的一个子集.

CVS为每个文件分配顺序版本号(1.1,1.2,1.3 ......).在Git中,版本号是40个字符的十六进制校验和.在SVN中,修订号在整个存储库中是顺序的; 给定的数字适用于整个存储库.

CVS允许您在签出时将版本号扩展到每个文件中,从而可以轻松识别文件的版本,而无需参考其来自的存储库.

因此,当存储库是大量不相关文件的集合时,我发现CVS(有时甚至是RCS)很方便,而且我更感兴趣的是跟踪单个文件的更改,但是整个存储库的修订并不是特别有意义.

(如果存储库包含用于构建单个程序或库的源文件,则不会出现这种情况;在这种情况下,您需要整个项目的连贯历史记录.)

最后,CVS将每个文件的历史记录存储在单个文件中(使用RCS使用的相同格式),格式相对简单.至少一次,我不得不手动重建已损坏的已保存的CVS文件.我不确定如何用SVN或Git做到这一点.

更新:这个问题引出了一些无法解释的暗示.我只能猜测原因(我并不担心偶尔的downvote),但也许有些读者认为我提倡CVS比SVN或Git更好的系统.我不是; 我只是指出CVS在一些相当狭窄的情况下可以有一些优势.

Answer 2

您必须了解Subversion是为了直接替换CVS以及开发人员对CVS的问题而编写的.编写了Subversion,因此CVS用户可以轻松地从CVS转换到Subversion,因为他们使用相同的工作流程和许多类似的概念.

这有点像问MS-DOS如何优于Windows作为操作系统.我可以想出一些虚假的原因(" 嗯......呃...... MS-DOS需要更少的内存. ").但是,最终,Windows是为了解决MS-DOS的缺点而编写的.

一旦你理解了推理,CVS对Subversion更好的一些原因根本就没有用处:

• 在CVS中,标签和分支是两个完全不同的概念.实际上,标签或分支之间没有太大区别.在CVS ,v文件中,分支和标记都在文件开头的特定修订中别名.实际上,您使用了相同的命令:cvs tag创建分支或标记.这是Subversion没有区分这两个概念的原因之一.但是,通过对分支和标签进行相同处理,Subversion确实为您提供了跟踪分支或标记历史记录的方法.是谁创造了它？它基于什么修订？它改变了吗？Subversion还为您提供了一种查看存储库中所有标记或分支的简便方法.在CVS中,您必须浏览每个文件.
• CVS比Subversion更灵活,因为Subversion或多或少会强迫您在整个目录中工作.在CVS中,您可以检查两者,进行更改,然后一次标记它们.当然,这真的是一种糟糕,可怕,可怕,危险的工作方式.通常发生的事情是你被告知要根据旧标签进行构建,然后将这些半打左右的文件更改.然后,创建一个新标签.当您尝试遵循这些指示时,会发生乐趣和兴奋.您是否在修订版1.3.4.2.3.2.5.2或1.3.2.4.3.2.5.2上创建了新标记？
• CVS允许您进行稀疏标记和分支.您可以拥有一个基本标记,然后在其上添加其他标记.当然,大多数网站这样做的原因是因为分支或标记一个非常大的CVS存储库可能需要数小时.Subversion在一微秒内完成同样的事情.
• CVS使用标准RCS文件格式,因此您可以修复存储库中的问题.但是,大多数情况下,您最终会产生比修复更多的问题.

CVS是对RCS的重大改进.在CVS中,您无需在更改文件之前锁定文件.在CVS中,您可以在不编写某种系统前端的情况下检出整个子树.RCS是为单个文件的版本而开发的.CVS将整个存储库版本化为单个项目.

RCS本身就是对SCCS的改进.RCS存储库格式更容易理解.关键字扩展效果更好,而且不那么神秘.您可以拥有分支分支,而SCCS只剩下一个分支级别.RCS具有内置的标签概念,而SCCS要求您自己跟踪标签.

SCCS比根本不使用源存储库要好得多.

事实上,CVS已被Subversion取代,因为Subversion在十多年前问世,所有关于CVS的工作都已停顿.我甚至不认为CVS上的错误会被修复.