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

毫无疑问，关于程序员工具的大多数争论都归结为个人选择（由用户）或设计重点，即根据特定用例优化设计（由工具构建者）。文本编辑器可能是最突出的例子-可以在Windows上工作并且在Mac上可以在Mac上的Haskell中进行编码的编码器，可以实现跨平台和编译器集成的价值，因此可以选择Emacs而不是TextMate等等。

事实证明，新引入的技术真正地优于现有的选件并不常见。

版本控制系统（VCS），尤其是集中式 VCS（CVS和SVN）与分布式 VCS（Git和Mercurial）是否真的是这种情况？

我使用SVN已有大约五年的时间，目前在我工作的地方使用SVN。不到三年前，我转到所有个人项目的Git（和GitHub）。

我可以想到Git相对于Subversion的许多优点（并且在很大程度上抽象出了分布式与集中式VCS相比的优点），但是我想不出一个相反的例子-一些任务（这一点很重要，并且在程序员中很常见）工作流程），Subversion比Git更好。

我从中得出的唯一结论是，我没有任何数据-并不是说Git更好，等等。

我的猜测是存在这样的反例，因此是这个问题。

Subversion是一个中央存储库

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

颠覆是传统观念

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

颠覆是一种方式，别无所求

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

其他优点是：

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

颠覆过了Git的一个好处可以是Subversion允许检查出唯一子树。使用Git，整个存储库是一个单元，您只能获得全部或一无所获。使用模块化代码，与Git子模块相比，这可能会很好。（虽然Git子模块也有自己的位置）。

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

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

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

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

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

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

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

我的理由：

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

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

我尝试过，亲自发现Git对我的小团队来说太多了。对于地理上分散的大型分布式团队或团队组来说，这似乎很棒。我非常了解Git的好处，但是我认为源代码控制并不能使我彻夜难眠。

我是鹿狩猎者，当我和我的朋友出去时，他们武装起来，牙齿the满，弹药和高科技装备刺满了牙齿。我带着一支步枪，七发子弹和一把降压刀出现。如果我需要进行七轮以上的比赛，那我做错了，我做的和其他人一样。

我要说的是，如果您是一个从事中小型项目的小型团队，并且已经熟悉SVN，则可以使用它。它肯定比CVS或（抖动）SourceSafe更好，并且建立存储库只用了不到五分钟的时间。有时候，Git可能会被过度杀伤。

这都是相对的，就像maple_shaft所说的那样，如果一个对您有用，那就不要改变！

但是，如果您确实想要某些东西，我想说它可能对设计师，Web程序员等来说更好-它处理图像和二进制文件要好一些。

可用性。它实际上并不是Subversion的优点，而是TortoiseSVN的优点。存在TortoiseGit，但要匹配TortoiseSVN还有很长的路要走。

如果您问什么Git比SVN更好，我会回复GitHub。有趣的是第三方工具如何发挥了如此巨大的作用。

当您不需要分支和合并时，SVN（在Windows上为TortoiseSVN）非常易于理解和使用。对于简单的情况，Git过于复杂，因为它试图简化分支/合并。

（如果管理好，许多小型项目就不必分支。Git针对复杂的情况；因此，大多数Git文档都假定您需要执行复杂的操作，如分支和合并。）

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

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

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

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

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

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

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

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

我将此作为回应而不是发表评论。

我承认，DVCS目前正处于趋势中，但我将尝试说明原因。

DVCS更好，因为就像很多人都在说：“这就是我们从一开始就应该进行的工作”。的确，您可以使用DVCS来实现与SVN相同的功能，从而使SVN变得过时。

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

• 长期项目从DVCS中受益匪浅，因为它使用的开销更少，允许更好的管理（分支等），并且受到google代码和github之类的主机的大力支持。

• 这些项目不是唯一的，在没有外部世界或互联网任何帮助的情况下，公司正在开发其他类型的项目：所有事情都是在内部完成的，通常是短期的。一个很好的例子：视频游戏。代码发展迅速。

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

• 开发人员拥有属于公司的机器，并且这种情况可能会迅速改变。配置存储库会浪费时间。
• 如果这些人没有自己的计算机，则他们不太可能使用相同的源代码/项目的一部分。再加上一个用于集中式数据。
• 网络速度和巨额资金允许使用可处理SVN一切的集中式服务器，这是不好的做法，但需要进行备份等。
• SVN只是使用更简单，即使这是错误的方式：在没有冗余的同级上同步文件也不是一个简单的问题，而“总是以正确的方式”只是无法始终如一地使它变得完美。

考虑一下游戏行业的机器以及SVN如何节省时间。人们在这些项目上进行了更多的交流，因为游戏是关于重复性编程和自适应代码的：没有什么很难编码的，但是必须尽快以正确的方式进行。雇用了程序员，他们编写自己的代码，进行编译，稍作测试，提交，完成，游戏测试人员将处理其余的工作。

DVCS专为互联网和非常复杂的项目而设计。SVN适用于小型，短期，紧密的团队项目。您不需要从SVN学到很多东西，它几乎是FTP的愚蠢差异。

Subversion和Git都鼓励使用特定（且非常不同）的开发和协作方法。根据组织和文化的不同，有些组织将从Git中获得更多收益，而另一些组织将从Subversion中获得更多收益。

Git和Mercurial都是非常优秀的专业程序员组成的分散且组织松散的团队的理想选择。这两种流行的DVCS工具都鼓励使用小型存储库，开发人员之间的重用是通过具有（相对）稳定接口的已发布库进行的。

另一方面，Subversion鼓励建立更加集中和紧密耦合的管理结构，在开发人员之间进行更多的交流，并增强对日常开发活动的组织控制程度。在这些组织更紧凑的团队中，开发人员之间的重用倾向于通过具有（相对）不稳定接口的未发布库进行。TortoiseSVN还允许Subversion支持具有非专业程序员（例如系统工程师，算法工程师或其他主题领域专家）成员的跨学科团队。

如果您的团队是分散的，成员要么在家工作，要么在许多不同的国际站点工作，或者如果他们希望独自工作并且保持沉默，几乎没有面对面的交流，那么像Git或Mercurial这样的DVCS将是一个不错的选择文化契合度。

另一方面，如果您的团队位于一个站点上，并且具有积极的“团队”开发方法，并且进行了很多面对面的交流，并且有“嗡嗡声”，那么SVN可能就是更好的文化适应性，特别是如果您有很多跨学科团队。

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

最后，我还发现，使用Svn下的“热”库开发（使用CI和测试驱动方法）共享功能可以实现协调开发的步伐，而对于分布更分散的团队来说，这是很难实现的。

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

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

现在，版本控制有两个主要趋势：分布和整合。

Git擅长下放权力。

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

使用SVN进行此操作的工具已经成熟，并且每天都在使用。

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

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

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