Subversion 与 CVS
我已经使用过一点 SVN 和 CVS，但需要为我即将开始的新项目选择一个。
广泛使用过这两种产品的人可以提供一些优点和缺点以及他们认为哪种更好吗？ 最好的学习资源也将受到赞赏。
这将是一个小项目，只有一两个开发人员启动。
I've used both SVN and CVS a little bit, but will need to choose one for a new project I will be starting.
Can anyone who has used both extensively please offer some pros and cons and which they think is better? Best learning resources would be appreciated too.
This will be for a small project, just one or two developers to start.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
我都用过。 没有可比性； 你想要svn。 使用 CVS 的唯一原因是因为您正在进入或接管遗留系统，而管理层不想改变现状。 如果您正在开始一个新项目，那么从逻辑上讲，不可能认为 CVS 比 Subversion 更好。
如果您用 google 搜索一下，您应该会发现大量的比较以及使用 Subversion 而非 CVS 的基本原理。 Subversion 相对于 CVS 的一些优点：
说了这么多，我建议您也探索一下一些分布式 VCS，例如 Bazaar、Mercurial 和 git。 我个人在我的所有项目中都使用 git。
I've used both. There is no comparison; you want svn. The only reason to use CVS is because you are entering or taking over a legacy system with management that does not want to change the status quo. If you are starting on a new project, it is virtually a logical impossibility to argue that CVS is better than Subversion.
If you google around, you should find plenty of comparisons, and rationales for using Subversion over CVS. Some of the advantages of Subversion over CVS:
Having said all this, I recommend you also explore some of the distributed VCSs like Bazaar, Mercurial and git. I personally use git on all my projects.
Subversion 比 CVS 有一些实质性的优势：
但是它有严重的缺点。 到目前为止，最大的问题是分支和标签并不是 svn 中的一等公民，它们只是遵守约定的目录。 除了失去真正的分支和标记的一些好处（在其他评论中提到）之外，它产生的最大问题是如果很容易搞砸。
Subversion 使用约定而不是配置意味着您需要提前考虑您的存储库结构并确保每个人都遵守它。 否则你会为子孙后代创造一个受伤的世界，更不用说任何需要理解你的仓库的工具了。
在 1.5 之前，合并和镜像几乎不存在（很好的帮助）。 1.5 已采取措施解决这两个问题，但仍有改进的空间。 颠覆中的合并仍然比需要的要困难得多。
SVN 优于 CVS 几乎是理所当然的事情。 然而，如果您不至少考虑一下 DVCS 必须提供的功能（Git、Hg、Bzr），或者您的预算允许的话，那么您就太失职了，有哪些声誉良好的商业工具（Accurev、Perforce）。
Subversion 可能是正确的选择，但您必须做好功课才能获得最佳结果。 从红皮书开始 http://svnbook.red-bean.com/
Subversion has some substantial wins over CVS:
However it has serious shortcomings. The biggest by far is that Branches and Tags are not first class citizens in svn, they are just directories that adhere to a convention. In addition to losing some of the benefits of real branching and tagging (mentioned in other comments) the biggest problem it creates is that if makes it very easy to screw up.
Subversion's use of convention rather than configuration means that you need to think about your repositories structure in advance and ensure that everyone adheres to it. Else you create a world of hurt for future generations, let alone any tools that need to grok your repo.
Merging and mirroring were almost non-existent (well assistance for) pre 1.5. 1.5 has taken steps to address both of these, but there is still room for improvement. Merging in subversion is still way harder than it needs to be.
SVN over CVS is almost a no-brainer. However, you would be remiss not to at least consider what DVCS's have to offer (Git, Hg, Bzr) or if your budget allows there are commercial tools with excellent reputations (Accurev, Perforce).
Subversion is probably the right choice, but you must do your homework to get the best results. Start with the Red Book http://svnbook.red-bean.com/
虽然在大多数情况下我会选择 Subversion 而不是 CVS，但您应该知道 Subversion 缺少什么：
CVS 将标签和分支视为不同的东西； 颠覆则不然。 这意味着构建在 Subversion 之上的第三方工具（例如具有源代码控制集成的 IDE）很难了解其中的差异。 您通常必须做一些特殊的配置来告诉它您的标签和分支在哪里，并且您必须确保您的用户坚持特定的文件系统布局。
Subversion 无法查看文件并告诉您某人在什么时候从该文件创建了分支或标记。 像 CVSGraph 这样的工具可以使用此信息来绘制文件历史记录的树。 要使用 Subversion 执行此操作，您需要搜索所有分支/标签目录，但我还没有看到任何工具可以很好地完成此操作。
根据我的经验，CVS 存在的时间更长，第三方工具更稳定。
根据我的经验，CVS 的存在时间更长，第三方工具更稳定
Although I would choose Subversion over CVS in most cases, you should know what you're missing with Subversion:
CVS sees tags and branches as different things; Subversion doesn't. This means that third-party tools built on top of Subversion (e.g. IDEs with source control integration) have a harder job knowing the difference. You usually have to do some special configuration to tell it where your tags and branches are, and you have to make sure that your users stick to a certain filesystem layout.
Subversion can't look at a file and tell you at what point someone created a branch or tag from it. Tools like CVSGraph can use this information to draw a tree of a file's history. To do that with Subversion, you'd need to search all the branch/tags directories, and I haven't seen any tools that do this well.
CVS has been around longer, and the third-party tools are more stable, in my experience.
你可以说我很守旧，但我更喜欢 CVS 下的分支/标记模型。
在 CVS 中，分支和标签是不同的东西。 标签是修订的标签。 它们对于标记要同步到网络服务器的文件的 生产 标签等事情非常有用。 您不必合并来更新 PRODUCTION 文件 - 您只需移动标记即可。
分支与主文件位于相同的“命名空间”中——很容易追踪特定文件的所有 mod。
在 SVN 中没有标签之类的东西。 那里只有树枝。 如果你想要标签，你需要创建一个分支并假装它是一个标签。 分支基本上是文件的副本。 上次我使用 SVN 进行分支/合并时，如果您希望将预分支文件合并回一起，则必须记录其修订版本（注意，我不是 SVN 专家，因此这可能已更改）。
话虽这么说，我认为 SVN 在其他方面都更好，您可能不应该使用 CVS 开始一个新项目。
Call me old fashioned, but I much preferred the branching/tagging model under CVS.
In CVS, branches and tags are different things. A tag is a label for a revision. They are super-useful for things like marking a PRODUCTION tag for files to sync to your webserver. You don't have to merge to update the PRODUCTION files -- you just move the tag.
Branches live in the same 'namespace' as the main file -- it's easy to track down all the mods of a particular file.
In SVN there is no such things as a tag. There's only branches. If you want tags, you need to create a branch and pretend it's a tag. Branches are basically copies of files. Last time I used SVN for branches/merges, you had to record the revision of the pre-branched file if you ever hoped to merge it back together (note, I'm not an SVN expert, so this may have changed).
That being said, I think SVN is better in every other respect and you probably shouldn't start a new project with CVS.
我怀疑你会得到很多答案。 他们甚至可能都同意。
在这两个选择之间，我相信毫无疑问您应该使用 Subversion。 Subversion 被构建为“更好的 CVS”，因此，没有人再主动维护 CVS。 Subversion 能够在不丢失历史记录的情况下重命名和移动文件，支持原子提交，具有更强大的存储库格式，具有更现代的访问方法，具有更好的第三方工具支持，等等。
You're going to get a lot of answers to this, I suspect. They might even all agree.
Between those two choices, I believe there is no question that you should use Subversion. Subversion was built as a "better CVS" and as a result, nobody actively maintains CVS any longer. Subversion has the ability to rename and move files without losing history, supports atomic commits, has a more robust repository format, has more modern access methods, has better third party tool support, and the list goes on.
Subversion 就像“更好的 CVS”。 它可以很好地处理移动文件和目录。 它具有分支支持，尽管不如分布式 VCS。
您还可以考虑使用分布式 VCS，例如 git、bazaar 或 Mercurial。
编辑：这是类似问题的链接
Subversion is like `a better CVS'. It handles moving files AND directories well. It has branching support, although that is inferior to Distributed VCSs.
You may also consider using a distributed VCS one like git, bazaar or mercurial.
Edit: Here is a link to a similar question
一般来说 Subversion .. 但是你应该注意资源问题。
当我在一家游戏公司工作时，我们有几个目录包含数百个小文件，而其他目录则包含数百个 meg 文件。 当我们从 CVS 切换到 Subversion 时，检查存储库的速度从一小时下降到四五个小时。 更新速度也慢得多。
与本机 csv pserver 相比，这几乎肯定是由于使用 http 或 ssh 来传输文件数据，但是由于通过 ssh 或 webdav 设置 svn 非常容易，因此人们往往不会考虑协议开销。 但是，您可以使用本机 svn 协议，这应该可以缓解该问题，我们没有在我的老公司对此进行测试。
另一个经常被忽视的问题是存储空间，我们发现subversion在本地使用的存储量确实是CVS的几倍。 我似乎记得它存储了存储库数据的本地副本以加快比较速度，除非您在存储库中存储了几千兆字节，否则这不会是一个大问题。
Generally Subversion .. However you should watch out for resource issues.
When I was working for a game company we had a few directories containing hundreds of tiny files, and other directories that contained a few hundred meg files. When we swapped from CVS to Subversion, the speed of checking out the repo decreased from one hour to four or five hours. Updating was also substantially slowr.
This is almost certainly due to using either http or ssh to transmit file data, compared to the native csv pserver, however since it is so easy to setup svn over ssh or webdav people tend not to think about the protocol overhead. You can however use a native svn protocol and this should alleviate the issue, we did not test this at my old company.
Another issue that is often ignored is storage space, we found that subversion did use several times as much storage locally as CVS. I seem to recall that it stores a local copy of the repo data to speed up diffing, this won't be a huge issue unless you store several gigabytes in your repository.
我已经使用 subversion 3.5 年了，现在我转到了其他使用 CVS 进行源代码控制的公司。 起初，两者之间没有太大区别，但是对于合并操作（这是我最关心的），我可以说 CVS 做得更好。 SVN 中分支/标签的概念很混乱，而 CVS 中则非常清晰。 CVS 中的合并（在我的例子中是集成分支）也比 SVN 中容易得多。
到目前为止，我认为 CVS 的弱点只是原子提交。 否则，这将是一个不错的选择。
I have used subversion for 3.5 years, now I moved to other company who uses CVS for source control. At first, there are not many differences between the two, but coming to merge operation (which is the top most of my concerns) I could say that CVS did a better job. The concepts of branches/tags in SVN are confusing while very clear in CVS. also merging (in my case, integrating a branch) is much easier in CVS than in SVN.
The weakness of CVS is so far in my idea only the atomic commit. otherwise, it would be good choice.