为什么选择Subversion而不是竞争对手？

Question

我个人以有限的方式使用Mercurial和Subversion，我不明白为什么95％的人会选择SVN而不是其他东西。它只是一个垄断案例，还是SVN中隐藏着很多其他系统没有的好东西？

Answer 1

它是免费的，是开源的，具有良好的文档，被广泛使用，简单/易于使用，具有重要的功能集，可在许多平台上使用，支持可用。

你可以问一个软件没有更多的东西。

EDIT 我知道它在处理分支和合并时没有其他工具那么好 - 但很多人要么接受它，要么使用该工具来避免合并。

其他原因之一是概念模型与CVS和SourceSafe的模型相匹配 - 因此人们不必掌握源控制和变化的不同思考方式。 （像Hg和Git那样）

我当然没有声称SVN比那些更好 - 只是回答它为何受欢迎。

Answer 2

• 大多数开发人员尚未习惯分布式源代码控制。从一个“传统”SCM到SVN的概念性转变较少。特别是它是CVS的自然迁移路径。
• 颠覆已经存在了很长时间。不要低估获得牵引力所需的时间。
• SVN不仅因为已经有多长时间而拥有更多的动力 - 它还拥有良好的记录。它已经稳定很长一段时间了，许多项目都信任它而不让它们失望。如果你是经理，那就是你想要听到的那种。
• Subversion与许多IDE很好地集成在一起。也许Mercurial的情况也是如此，但肯定不是git。

就我个人而言，我刚刚开始使用git作为Subversion粉丝很长一段时间。我对Subversion更加满意，但否认分布式源代码控制的优势是愚蠢的......

Answer 3

一切都与支持有关。

• 文档支持
• IDE的支持
• 托管公司的支持
• 企业级支持

支持，支持和支持。

Answer 4

CVS曾经是默认的（它几乎是唯一的答案）。 SVN被明确地设计为更好的CVS。有意义的是，许多CVS用户将迁移到SVN，因为它几乎修复了所有CVS的故障，更易于使用和维护，添加了新功能，并且具有非常简单的迁移路径。

SVN也存在一些问题，但通常只有高级用户会遇到这些问题。像Git和Mercurial这样的系统似乎解决了这些问题（我只是略微涉及git，从不善变）。 SVN对于大多数用途来说已经足够好了，并且拥有用户群，社区和工具支持，使其成为刚刚入门的人们非常有吸引力的选择。

Answer 5

不是每个人都使用SVN，我们中的一些人正在使用GIT ...;）

Answer 6

我发现设置起来非常快。如果我使用VisualSVN服务器（免费）和AnkhSVN VS插件（也是免费的）并添加TortoiseSVN shell扩展，我可以在源代码控制下加上3个客户端超过20分钟。像饼一样容易......得到很好的支持......

那里最好的吗？可能不是。但它确实很容易设置。

Answer 7

许多人来自CVS，Subversion可能是最像CVS的SCM，因此很容易学习。

Answer 8

对于集中版本控制，它是安全选项，它足够好并且每个人都在使用它。与TortioseSVN等工具一起使用它非常好。可能有更好的解决方案，但它们不是免费的，不是众所周知的，或两者兼而有之。

分散版本控制符合OSS的工作方式，但我认为大多数公司都不会使用它。跟踪更改和版本似乎更难。拥有许多不同版本的代码更容易解​​决，并且已经解决了许多不同的错误排列和实现的功能，而且很难向管理层出售。

Answer 9

GUI的。

根据我的经验，没有技术人员使用版本控制是一个艰难的过程。为他们提供一个漂亮的GUI并告诉他们通过右键单击更新/提交是他们唯一的方式来使用它。

现在，如果只有git有一个干净，可用的GUI，那么它真的会起飞。

Answer 10

出于我们的目的，它很容易站起来，易于使用，并且在我们选择的IDE中具有良好的集成工具。它是最好的吗？也许不是，但就中央存储库而言，它可以解决问题。

Answer 11

在大约半天左右的时间里，我安装了SVN并对Windows域帐户进行身份验证（使用Apache）识别域名组。虽然我使用Windows和Unix进行开发，但该公司的后端服务都是微软。在Microsoft环境下轻松设置这一事实非常棒。

我们没有做任何想象，因为这里的大多数开发人员拥有他们的整个项目（我们还没有做任何合并）。而且由于任何人（有权限）都可以在浏览器中查看存储库，因此这是分发版本的好方法。

Answer 12

对我来说：免费，良好的文档，通过TortoiseSVN与Windows的良好集成以及成为CVS标准和自然继承者的看法使其成为一个非常明显的选择。

Answer 13

我实际上看过Mercurial是Subversion的替代品......我真的很喜欢Mercurial的命令语法。然后我做了一个小实验。我拿了Boost的tar球，解压缩并试图将它检入Mercurial存储库。

我在Windows和Unix上做过这个。由于Mercurial中的一些路径深度错误，它在Windows上失败了。

Subversion和git没有问题（bazaar，IIRC也没有）。我不喜欢Darc的命令语法。 Git有腐烂的窗口支持（需要Cygwin或MSYS），几乎没有人听说过Bazaar ......所以我和Subversion呆在一起。

Answer 14

它是免费的，稳定的，独立于平台的，易于部署，易于集成到IDE中，并且被广泛使用。

这是我使用它的原因。

Answer 15

这是人们所知道的。没有更多的东西。 是的，一旦它设置好（这可能很痛苦），它很容易使用，是的，它与大多数IDE集成良好，是的，有很好的工具可用（例如TortoiseSVN），是的，它已经稳定了很长时间时间，但所有这些事情只是意味着大多数人都没有看到迫切需要甚至看替代品。

它基本上被广泛使用因为它被广泛使用。人们熟悉它，几乎每个人都“默认”使用它。

我仍然习惯于Bazaar以及分散式SCM的想法，但我已经或多或少地确信它对于几乎任何项目来说都是更好的模型。但这是一场艰难的斗争，因为这是一个人们必须习惯并融入其工作流程的新概念。

Answer 16

我们不只是使用Subversion - 在早期我们使用Source Safe（远离），然后我们增长并需要分支，所以我们切换到TFS。

TFS真的很难以这种方式使用。不方便用户使用。完全没有。对于像我们这样的小型手术（5个开发者），感觉非常臃肿。

此外，TFS与SharePoint有这种邪恶的共生关系，这对我们来说是坏事。如果我们拥有更多的IT资源并且可能是我们可以投入到这些迷宫领域的开发人员，这不会是一个问题，但是我们的SharePoint安装有一些严重的IT崩溃让我们对我们的源头感到害怕。

因为它的分支是如此神秘，它失败了我们实现它的任务！

我们在大约一个月前使用VisualSVN作为我们的客户（费用为50美元/座位，但比免费的AnkhSVN更精致）切换到Subversion。 VisualSVN建立在Tortoise之上，效果很好。

我最喜欢的Subversion之一是它可以将你的代码存储为文本文件，而不是存储在专有数据库中（尽管它可以使用BerkleyDB作为后端，但性能优势通常是可以忽略不计的）。因此，您不会遇到SharePoint发生故障并且您的代码很难获得或者可能（gulp）消失的情况。它只是磁盘上的文本文件。

所以，它是免费的，精简的，易于使用的，它只是起作用。我对Subversion非常满意。

Answer 17

它是免费的，易于管理，具有小型组织所需的基本功能。

但根据我的经验，它无法击败商业替代品（特别是AccuRev，还有ClearCase，Perforce等），这将比svn更适合你。

Answer 18

除了被广泛使用之外，您还可以找到提供SVN存储库的托管服务的规模。但是，我同意...... SVN有一些痛苦。

Answer 19

SVN看起来很有希望，但在尝试了几个项目之后，我又回到了CVS。它很简单，而且很有效。

我写了一篇关于此的博文，其结尾的句子是：“我越是想到它，SVN似乎是一个理论问题的书呆子实现，而CVS是一个真实生活情境的实用解决方案。“

如果您愿意，可以在此处找到完整的帖子： http://www.rolfje.com/2008/02/16/svn-is-missing-the-point/

Answer 20

在我的公司，我们一直在使用Subversion和TortoiseSVN取代Visual Sourcesafe（哎呀，是的，我知道），总的来说，这是一次非常积极的体验。

我们有一个真正重要的负面问题反对颠覆：任何针对基于Apache服务器的SVN使用的1.5.X版本都会泄漏内存，而对于我们的使用模式来说，它很糟糕，它往往会多次崩溃服务器一天。如果我没记错的话，我们不得不恢复到1.4.8版本，这引起了一些惊愕。
幸运的是，有一些Python脚本可以帮助将工作副本还原回旧版本的SVN。

Answer 21

它比人们以前用过的CVS要好得多。它有这么少的缺点，人们没有这种感觉，他们应该尝试别的东西。 Subversion足以满足大多数需求，所以他们不会尝试其他任何东西，即使它可能更有效率。我还没有使用mercurial（我想尝试一下，但是没有时间，而且由于SVN的工作，我的列表没有高优先级。）

此外，分布式版本控制在开始时开始变得更加复杂，因此人们可能会受到惊吓。