为什么要使用SVN？有没有隐藏的专业人士（通过GIT / Mercurial / Bazaar）？

Question

  

可能重复：
  Why is git better than Subversion?

我已经阅读过很多（虽然不足以得到完美的图片）关于版本控制系统，显而易见的结论是GIT是最好的。或者是Bazaar。或Mercurial。但如果是这样，那么没有人会使用SVN，但他们仍然这样做。为什么？我自己对v.c.s.的看法没有自己的意见。通常是最好的，因为他们缺乏经验。你能分享一下自己的想法吗？

Answer 1

我目前正在为美国研究机构维护版本控制服务。除了Git和Mercurial之外，我们不仅支持SVN，还支持CVS。

SVN在我们的用户中的“杀手级功能”是狭窄的克隆。您可以在层次结构中只检查一个子目录，只下载与该目录相关的文件，并且仍然可以进行提交。 Git最近在这个称为稀疏检出的功能上给出了一个类似但不太有用的变体（另请参阅Sparse checkout in Git 1.7.0?）。这使您可以过滤工作树，但仍然会强制您下载整个项目的整个历史记录，即使大型二进制文件不在中也可能会令人望而却步。请注意，磁盘很便宜，如果你事先吸收初始克隆的命中，后续拉动速度足够快，但是这对于那些在他们意识到需要克隆之前就已经旅行的人没有帮助，无论如何甚至Git的稀疏检查不会让你开始工作树五层，所以它看起来有点难看。

此外，用户比Git提交钩子更容易编写authz文件，比任何DVCS更容易使用SVN语法和方法，也许最重要的是，已经有数千个承诺在SVN中有历史价值。将大型Subversion存储库迁移到Git或Mercurial的实验提供了不同的结果，这些科学家试图在他们自己的项目上完成工作，而不是将时间花在开发DVCS上。

由于类似的原因，CVS仍有以下情况。想象一下，作为一个Git用户，它具有稀疏检出功能，允许您随意重新映射分支中的文件显示在工作树中的位置，使用与存储库一起版本化的格式，并按照通常的拉动进行分发，这样您就可以编写可以包含其他组的组的定义，并且只删除克隆上文件系统放置所需的文件。这在CVS模块中很简单，在每个DVCS中都是不可能的。对于CVS的所有罪行（并且相信我，我们非常了解它们，并且不顾一切地阻止新的CVS项目，除非它们绝对不能没有模块），所以不可能说服使用该功能的团队迁移到另一个版本控制系统。

DVCS软件带来了一些令人敬畏的创新，但它们也缺少一些开发人员认为理所当然的东西。在选择之前，请确保事先知道您的要求。

Answer 2

谈论我工作的公司 - 使用SVN的最大原因是能够在版本控制下保留庞大的专有格式二进制文件。特别是，数以千计的CAD文件库。在这种情况下，确实让VCS像SVN一样基于文件，而不是像Git那样基于文本信息。

暂且不管你是否可以用Git进行浅层“结账”，或者它存储二进制数据的程度如何，事实上它是设计来跟踪浮动在树周围的文本信息行。源代码。除此之外，该模型不适合跟踪二进制数据库。

老实说，这是我推荐它的唯一可靠理由：P

Answer 3

SVN已经建立并成熟，具有同样成熟的工具。

Answer 4

除了人们提到的其他事情（大量的二进制数据，成熟，稳定等）之外，svn是建立在经典的分层模型之上的，这与基于补丁/变更的修订有根本的区别。

我们公司决定继续使用SVN，因为这种模式符合我们处理发布周期和分支的方式。我们认为版本的直接进展是一种恩惠，而不是一种祸根。更新被推送到集中式存储库，并且某些被视为“稳定”的修订被签出到实时环境中。在任何时候，都可以立即清楚每个环境对所有相关人员的状态。 （是的，这可以通过git实现。）即使对版本控制或软件开发一无所知的管理人员也可以说：“我们喜欢你在版本2547时的使用方式”。

另一方面，我应该提一下，我将darcs和git用于我和我的朋友以及合作FOSS的工作项目，因为基于补丁的分布式模型适用于我们。我们可以临时推进项目的时间表，并挑选各种变化。

我的公司SVN的优势在于其强大的层次结构和对非熟悉“登录”和“下载”概念的非程序员的可访问性。

Answer 5

当存储库包含大量二进制数据时，Subversion具有优势，而二进制数据不能很好地进行增量压缩。 Subversion checkout只抓住头部，但是git克隆了整个历史记录，它的重量可以达到几千兆字节。是的，这对于飞行模式来说很不错，但是获取初始克隆可能需要几个小时。

Answer 6

人们仍在使用Subversion，因为它是使用第一个范例来设计版本控制系统（集中式）。切换到分布式（基于更改而不是基于版本）可能需要一些时间才能习惯（正如您在Joel's experience中看到的那样），并且由于抵制变化，许多团队决定不使用它。

Mercurial工具非常成熟，在我看来与SVN相当。

Answer 7

虽然svn成熟/成熟，我不得不承认，Kenji Kina是对的：它过去生活的版本控制模型已经过时了。我只使用过svn，但在阅读/观看Linus和Joel谈论DVCS之后，这听起来是个好主意。我认为Perforce做了类似的事情。

这并不意味着svn很糟糕（它工作得相当好！），但是管理代码更容易，并且更频繁地提交DVCS。因为如果你破坏某些东西，它很容易撤消。如果你分支，它很容易合并。总的来说，他们修复了Subversion最常见的许多麻烦。

如果您以前从未使用过其他版本控制系统，并且自己部署它并且编写代码（而不是文档或图片或者您不需要文本内容/差异的东西），请自己做一个赞成并研究DVCS。那么你不需要re-educated。

Answer 8

完成此http://www.stevestreeting.com/2009/09/28/early-stage-gitmercurialbazaar-evaluation-thoughts/