SVN比Git有什么优势？ [关闭]

#1 楼

Subversion是一个中央存储库

虽然很多人希望拥有分布式存储库以明显提高速度和多个副本的好处，但在某些情况下，更希望使用中央存储库。例如，如果您有一些关键的代码段，不想让任何人访问，则可能不希望将其放在Git下。许多公司希望将其代码集中化，并且（我猜）所有（严肃的）政府项目都在中央存储库中。

颠覆是传统常识

这就是说许多人（尤其是经理和老板）拥有通常的方式来对版本进行编号，并将其视为硬编码到他们大脑中的“单行”。没有冒犯，但是Git的自由并不容易吞噬。任何Git书籍的第一章都告诉您将所有常规的理想从头脑中清除，然后重新开始。

Subversion是一种方式，而其他什么都没有。版本控制系统。它有一种完成工作的方式，每个人都以相同的方式进行。期。这使得从其他集中式VCS到SVN的过渡变得容易。 Git甚至不是一个纯粹的VCS，它是一个文件系统，具有许多拓扑结构，可用于在不同情况下设置存储库-而且没有任何标准。

其他优点是：


SVN支持空目录
SVN具有更好的Windows支持可以检出/克隆子树
SVN支持专有的访问控制svn lock，该功能对于难以合并的文件很有用
SVN更容易支持二进制文件和大文件（并且不需要复制旧文件版本。）
添加提交涉及的步骤要少得多，因为没有任何拉/推操作，并且您的本地更改始终基于svn update隐式地重新建立。

#2 楼

Subversion与Git相比的一个好处是Subversion仅允许检出子树。使用Git，整个存储库是一个单元，您只能获得全部或一无所获。使用模块化代码，与Git子模块相比，这可能会很好。 （显然，尽管Git子模块也有其位置。）

还有一点点小好处：Subversion可以跟踪空目录。 Git跟踪文件内容，因此不会显示没有任何文件的目录。

#3 楼

我可以想到三个。首先，使用它比较容易，特别是对于非开发人员而言。从概念上讲，它比DCVS选项要简单得多。其次是成熟度，尤其是Windows上的TortoiseSVN。不过，TortoiseHg正在快速追赶。第三，在某些情况下，野兽的本质（就像一个文件系统的映像，您可以从树的任何级别检出内容）可以派上用场，例如对数十种不同的配置文件进行版本控制没有数十个存储库的服务器数量。

这并不是说我们没有将所有开发转移到Mercurial。

#4 楼

从管理员和管理员的角度来看，SVN存储库更易于管理（ACL +身份验证方法+热拷贝+镜像+转储）
SVN *-钩子易于实现和支持
> svn:external比子模块具有更强大的功能和灵活性
基于文件系统的存储库树比仅具有逻辑分隔的单片存储库更易于使用
SVN具有更多不同的客户端工具
SVN具有第三方可用的Web前端，比Git的要好得多。
SVN不会伤脑筋

#5 楼

我将此内容写为对其他人的答案的评论，但我想它本身应该是一个答案。

我公司为SVN精心选择的配置需要文件级锁定才能编辑内容，永远不会使用合并。结果，多个开发人员争夺锁，这可能是一个主要瓶颈，而且永远不会发生合并冲突。

SVN绝对比Git做得更好。在我向git进行的skunkworks迁移中（要求宽恕而不是许可），我的经理吓坏了很多次，因为没有任何软件强制的中央主控服务器，我们都是从属服务器。

#6 楼

我很高兴您正在寻找有用的信息，但是这种问题只会引起您的注意：“我认为Git赢了很多，所以svn teh suxorz！”答案。

我尝试过，亲自发现Git对我的小团队来说太多了。对于分散在地理位置上的大型分布式团队或团队组来说，这似乎很棒。我非常了解Git的好处，但是我认为源代码控制并不能使我彻夜难眠。用弹药和高科技装备刷满牙齿。我带着一支步枪，七发子弹和一把降压刀出现。如果我需要七个以上的回合，那么我在做错事，那么我做的和其他人一样好。

我要说的是，如果您是一支中等规模的团队，小型项目，您已经熟悉SVN，然后使用它。它肯定比CVS或（抖动）SourceSafe更好，并且建立存储库只花了我不到五分钟的时间。 Git有时可能会造成过大杀伤力。

#7 楼

我的原因：


成熟度-服务器和工具（例如TortoiseSVN）
简单-涉及的步骤更少，一次提交就是一次提交。 DVCS（如Git和Mercurial）先进行提交，然后进行推送。
二进制处理-SVN比Git / Hg更好地处理二进制可执行文件和映像。由于我喜欢将与构建相关的工具检入源代码管理，因此对.NET项目尤其有用。
编号-SVN具有可读的提交编号方案，仅使用数字-易于跟踪修订版本号。 Git和Hg的做法大不相同。

#8 楼

这都是相对的，就像maple_shaft所说的那样，如果一个对您有用，就不要改变！这样-它可以更好地处理图像和二进制文件。

#9 楼

可用性。它并不是Subversion的优点，而是TortoiseSVN的优点。.TortoiseGit存在，但要匹配TortoiseSVN仍有很长的路要走。有趣的是第三方工具如何发挥了如此巨大的作用。

#10 楼

当您不需要分支和合并时，SVN（在Windows上为TortoiseSVN）非常易于理解和使用。对于简单的案例，Git过于复杂，因为它试图简化分支/合并。 ;因此大多数Git文档都假定您需要执行复杂的操作，例如分支和合并。）

#11 楼

好吧，我的祖父可以在Windows XP计算机上使用SVN，但是他在使用Git时遇到了麻烦。也许这是TortoiseSVN优于TortoiseGit的一项成就，但我认为这与以下事实联系在一起：Git本质上更加强大，因此更加复杂，将其降低到相同水平毫无意义。

现在对我的祖父而言，这并不重要，因为他最近没有进行任何编程。但是，我曾经在一个团队中工作，我们的图形艺术家也在使用我们的源代码控制。

这些人只是希望他们的工具能够工作（我也是，但是我有现实的机会让他们在失败的情况下工作）并且很直观。除了事实，要让他们与DVCS相处还需要很大的努力，但收获不多。在团队中只有两名程序员的情况下，我们也应该坚持使用SVN。

#12 楼

在工作中，由于以下两个原因，我无法将开发人员从SVN切换到任何DVCS：


部分签出（例如，项目树中只有三个不同深度的文件夹）
文件锁定（二进制格式的报告）

#13 楼

进行“ svn提交”时的安全感。由于将提交提交到服务器，因此我无法做任何修改，以免在提交更改后删除更改。在git中，提交是本地的，因此在我推送之前，一个流浪的'rm -rf'都结束了。
提交已通过身份验证。默认情况下，我可以在git中告诉我我以任何人的身份提交。
需要更少的命令来学习日常使用。 'svn checkout'，'svn up'和'svn commit'将使您走得更远。
共享的Checkout效果更好。当您提交时，它会要求您提供用户名/密码，而不必记住要传递某些命令行参数。有时在工作中，我们有一台共享的机器，并且共享了某些项目的svn签出。有人可能会说“ Bob，您可以在这台机器上查看它吗”，他可以，而且他可以以用户身份进行更改，而不会费劲。
存储库布局。您可以有一个伞形项目和子项目，然后选择要检出的内容。
修订号是递增的整数。
专为中央存储库工作流而设计。

#14 楼

速度。克隆大型git仓库有时需要10到15分钟，而类似大小的subversion仓库则需要几分钟才能检出。

#15 楼

其他人已经发布了一些很好的答案，但是权限呢？使用基于SSH的Subversion，您可以在服务器上为SVN创建一个单独的帐户。可以为不同的开发人员提供对存储库不同部分的不同访问权限。 GIT可以做到吗？我猜那里有一种乙醇钛矿，但对我来说似乎并不灵活或健壮，也不知道实际上有人在使用它。

#16 楼

我将此作为回应而不是发表评论。更好，因为就像很多人都在说：“这就是我们从一开始就应该进行的工作方式”。没错，您可以使用DVCS来实现与SVN相同的功能，从而以某种方式使SVN过时。

但是，并不是每个软件项目都像它得到的一样好：

长期项目从DVCS中受益匪浅，因为它使用的开销更少，可以更好地进行管理（分支等），并受到google代码和github之类的主机的大力支持。项目不是唯一的项目，在没有外部世界或互联网任何帮助的情况下，公司正在开发其他类型的项目：所有事情都是在内部完成的，而且通常是短期的。一个很好的例子：视频游戏。代码发展迅速。

对于后一种情况，开发人员并不真正需要DVCS可以提供​​的分支或复杂功能，他们只想共享源代码和资产。他们编写的代码不太可能被重用，因为有最后期限。由于以下几个原因，他们依赖SVN而不是DVCS：


开发人员拥有属于该公司的计算机，并且这可能会迅速改变。配置存储库会浪费时间。
如果这些人没有自己的计算机，则他们不太可能使用相同的源代码/项目的一部分。再加上一个用于集中式数据的数据。
网络速度快，资金大，允许使用处理所有SVN的集中式服务器，这是不好的做法，但是可以进行备份。如果使用的是错误的方法：在同级上没有冗余地同步文件不是一个简单的问题，并且如果您始终希望它是完美的，那么“以正确的方式进行操作”就无法及时做到。

考虑一下游戏行业的机器以及SVN如何节省时间。人们在这些项目上进行了更多的交流，因为游戏是关于重复性编程和自适应代码的：没有什么很难编写的，但必须尽快以正确的方式进行。雇用了程序员，他们编写自己的部分，对其进行编码，一点点测试，提交，完成，然后由游戏测试人员处理其余的事情。 SVN用于小型，短期，紧密的团队项目。您不需要从SVN中学到很多东西，它几乎是带有愚蠢差异的FTP。

#17 楼

Subversion和Git都鼓励使用特定（且非常不同）的开发和协作方法。有些组织可以从Git中获得更多收益，而其他组织则可以从Subversion中获得更多收益，这取决于它们的组织和文化。 。这两种流行的DVCS工具都鼓励使用小型存储库，而开发人员之间的重用是通过具有（相对）稳定接口的已发布库进行的。 ，开发人员之间的交流越来越多，并且对日常开发活动的组织控制程度更高。在这些组织更紧凑的团队中，开发人员之间的重用倾向于通过具有（相对）不稳定接口的未发布库进行。 TortoiseSVN还允许Subversion支持非专业程序员（例如系统工程师，算法工程师或其他主题领域专家）成员的跨学科团队。

如果您的团队是分布式的，则成员要么在家工作或来自许多不同的国际站点，或者如果他们更喜欢独自工作并保持沉默，几乎没有面对面的交流，那么像Git或Mercurial这样的DVCS将是很好的文化选择。

如果，另一方面，您的团队位于一个站点上，采用了积极的“团队”开发方法，并且进行了很多面对面的交流，并且在空中“嗡嗡作响”，因此SVN可能会更好文化适应性，特别是如果您有很多跨学科团队。

当然，可以配置Git和Hg（功能强大且灵活）以执行几乎任何您想做的事，但这肯定是更多的工作，而且它们肯定更难使用，特别是对于那些团队成员来说最后，我自然不会倾向于使用任何形式的版本控制。

最后，我还发现在Svn下使用“热”库开发（使用CI和测试驱动方法）共享功能可以更加分散和松散的团队难以实现协调发展的步伐。

#18 楼

以下是我仍然使用SVN的两个原因。

学习曲线。 SVN比Git更容易，甚至包括设置（服务器或客户端），可用性和命令也更容易。
更好的服务器软件包，例如Subversion Edge，VisualSVN，uberSVN等。

评论

---

为＃1 +1。在这里比较SVN和GIT图表steveko.wordpress.com/2012/02/24/10-things-i-hate-about-git

– s_t_e_v_e
14年1月1日在16:58

---

#19 楼

目前，版本控制有两个主要趋势：分发和集成。

Git非常适合分散。

SVN内置了许多与其集成的工具。设置SVN服务器是很常见的，以便在签入修复程序时在签入注释中提及错误号，它会自动将其设置为“处于测试中”状态，并提醒指定的测试人员需要看它。然后，您可以标记一个发行版，并获取此发行版中已修复的所有错误的列表。

#20 楼

在Subversion中，可以在完成提交并推送之后编辑日志消息（也称为“提交消息”）。对于大多数实际用途，通过设计在分散系统（包括git）中是不可能的。当然，在git中，您可以执行“ git commit --amend”，但是在将您的提交推送到其他位置后，这无济于事。在SVN中，当您编辑日志消息时，您是在每个人都共享的中央存储库上进行操作，因此每个人都可以进行编辑，而修订版本的标识符不会更改。

事实通常非常有用。除了仅修正日志消息中的错误或遗漏之外，它还使您能够执行诸如更新日志消息以引用将来的提交之类的事情（例如修正错误或完成当前修订中引入的工作的修订） 。

顺便说一下，没有丢失信息的危险。如果您真的担心，pre-revprop-change和post-revprop-change钩子可以保存旧消息的历史记录，或者发送带有日志消息diff的电子邮件（实际上，这比较常见），因此审核跟踪。