logo标签列表

SVN相比Git有哪些优势？

svngit
22

我正在深入学习Git，尽管我以前并未完全掌握SVN。这是我第一次认真学习源代码控制管理系统。

我在想，如果不去学习（或者甚至反学就算了）SVN，会有什么机会成本吗？有没有我需要特别注意的事情？

Git相比于SVN来说，是否存在一些无法做到或者非常困难的事情呢？

你看过这个吗： https://dev59.com/TXVC5IYBdhLWcg3w21Iq? - Sander
@Sander...我已经浏览了SO上关于这个问题的大部分内容，但是没有找到什么能够令人满意地解决这个问题的东西。你链接的那个问题已经有两年半的历史了...在这个领域，这已经相当于两个半世纪的时间了。无论如何，我也看过那个帖子了。 - explorer
当然可以，但是如果您在问题中展示一些努力，那会更有帮助；这样其他人就知道您已经付出了一些努力，这有助于更好地回答问题！ - Sander
在我看来，更好的做法是反过来问：“svn不能做什么，而git可以做什么？” ;) Git可以轻松地在分支之间切换，并且当我移动、删除、移除文件夹/文件时不会卡住。 - Andrew Orsich
FYI：http://svnvsgit.com/ - bahrep
13个回答
15

Git无法svn lock文档，因此有人可以防止其他人编辑不可自动合并的实体（例如Word或Excel文件）。

1
除非在服务器端进行，否则像Git这样的分布式版本控制系统的锁定并没有太多意义。 - Mot
@MikeL：当然可以。实际上，git并没有根本性的原因不支持这个功能。只是还没有被实现而已。当然，在你在线的时候才能使用锁定功能。 - sleske
@sleske：Git旨在作为版本控制系统，而不是访问控制系统。虽然有第三方软件可以在Git之上实现这一点（例如gitolite），但是像pull/merge请求这样的机制以比锁定文件更明智的方式处理此问题。 - Emilia Bopp
1
@aepsil0n：我认为你误解了。SVN文件锁定不是访问控制机制（它可以被覆盖）- 它是一种避免两个人同时编辑同一文件的机制。这对于难以合并的文件（例如图像文件）非常有用。 - sleske
你说得对，我确实误解了。感谢澄清。这不是和 Git 默认不允许推送冲突更改差不多吗？我的意思是，最终什么也阻止不了你在本地编辑。我很难看到这个功能在分布式版本控制系统的环境中有什么用处。 - Emilia Bopp
1
@aepsil0n：是的，它们大致相似。不同之处在于，使用SVN锁定时，在编辑文件之前*锁定（或应该锁定）文件-因此两个人不能在不知道的情况下编辑同一文件。Git中没有这样的机制，您只能在事后发现。 - sleske
14

Git无法检出子树并像完整的存储库一样使用。

例如，使用Subversion可以检出目录“trunk”，并将其用作存储库。您还可以检出“branches / feature1”并使用它。在Git中，只能检出根目录（尽管在最近的版本中，您可以进行稀疏检出，不会下载所有文件，但仍然需要检出根目录）。在Git中，您应该使用分支而不是检出子树。

4
实际上，SVN 也不能将子目录作为完整的仓库进行检出。无论是 SVN 工作副本还是 Git 工作树都不是仓库。在 Git 中，你确实可以检出子目录：git checkout <子目录名称>。该命令检出存储库中的文件子目录，就像 SVN 可以一样——只要先克隆存储库即可。在 SVN 中，之所以不必先克隆存储库，是因为 SVN 不是一种分布式版本控制系统......什么？你为什么那样看着我？ - Dan Moulding
3
@DanMoulding：没错。然而，实际上，SVN允许你检出子树并从中提交。在Git中，你不能以一种允许你提交并将提交推送到上游的方式获取一个子树。 - sleske
Git有http://programmers.stackexchange.com/questions/111633/what-does-svn-do-better-than-git#comment-336451。 - Pacerier
13
我认为你可能更愿意使用Subversion而不是git的少数用例之一是，如果你正在尝试管理一个非常大的二进制媒体库，人们大多只想要最新版本。例如，假设你正在开发一款游戏，艺术家需要跟踪所有艺术品的修订版，但整个仓库的历史记录将会很大（数百GB）。
公平地说，这是一个非常远离git设计目的（管理源代码存储库）的用例，如果你真的想在这方面使用git，有各种解决方法或扩展可以帮助你，例如：
- 浅克隆 - Scott Chacon的git-media扩展程序 - Joey Hess的类似项目git annex - 使用Avery Pennarun的bup直接创建打包文件
...但这仍然是一个你可能更喜欢使用SVN的领域。几年前的GitTogether上有一份简短的演示文稿介绍了这个主题。
8

Git无法存储空目录。可以说这是一个优点，但这是git不能做到而svn可以的一件事。

2
并非在所有情况下都是优势，因为有时包含没有源代码的目录也很重要。例如，当您想要跟踪目录树上的修订版本，这些目录树是您打包项目的“源”时。 - Edwin Buck
4

这个维基页面有一个很好的比较: https://git.wiki.kernel.org/index.php/GitSvnComparison

总结

  • Git比Subversion快得多
  • Subversion允许您只检出存储库的子树; Git需要您克隆整个存储库(包括历史记录)，并创建一个工作副本，该副本镜像至少一部分在版本控制下的项目。
  • Git的存储库比Subversion小得多(对于Mozilla项目，小30倍)
  • Git从一开始就被设计为完全分布式，允许每个开发人员具有完全的本地控制
  • Git分支比Subversion的更简单、资源更少
  • Git分支携带它们的全部历史记录
  • 在Git中合并不需要您记住从哪个版本进行了合并(随着Subversion 1.5的发布，这种好处已经被废除)
  • Git提供了更好的分支和合并事件审计
  • Git的存储库文件格式很简单，因此修复容易，损坏很少发生。
  • 集中备份Subversion存储库可能更简单-因为您可以选择在git中分发存储库中的文件夹
  • Git存储库克隆作为完整的存储库备份
  • Subversion的用户界面比Git的更成熟
  • 在Subversion中遍历版本更简单，因为它使用连续的修订号(1,2,3,..); Git使用不可预测的SHA-1哈希。使用"^"语法在Git中向后遍历很容易，但没有简单的方法向前遍历。
6
探险者并没有询问Git相对于SVN的优势，而是询问其劣势。 - Mot
1
你所参考的维基页面在http://svnvsgit.com/上有很多问题。你只是复制粘贴了错误的信息。 - bahrep
感谢@bahrep的评论，不过它发布于将近4年前。您能否说明根据您的信息有哪些不准确之处？ - Sander
1
@Sander Git的代码库比Subversion小得多（对于Mozilla项目，小了30倍），Git的分支比Subversion简单且资源消耗更少，Git的分支携带其完整的历史记录（SVN分支也携带整个历史记录），Git提供更好的分支和合并事件审计，而且Git的仓库文件格式简单，因此修复容易且损坏很少发生。 - bahrep
3
  • Git在文件名和提交信息中不支持非US-ASCII字符（跨平台），git只是存储从操作系统获取的字符的字节表示，而不是进行转换。
  • Git无法记录哪些特定的提交已经被cherry-pick。
4
除非你专门配置存储库使用旧编码，否则Git提交消息始终采用UTF-8编码，因此Git完全支持提交消息中的所有Unicode字符。 - CB Bailey
根据我（相当有限的）对Git的了解，它不会将特定于平台的文本编码转换为UTF-8，但SVN肯定会这样做。 - Mot
在提交消息中使用UTF-8通常不会有问题 - 您只需要一个理解UTF-8的编辑器。文件名中的UTF-8现在也应该可以工作了，至少在Windows上是这样。它在Cygwin+git中肯定可以工作，并且msysgit显然在1.7.10中修复了它（https://dev59.com/WnRA5IYBdhLWcg3wyBD1#1274142）。 - sleske
然而，在MacOS上，UTF-8文件名似乎仍然存在问题，因为HFS +应用了Unicode规范化。 - sleske
3

对于我们来说，SVN最重要的功能是具有全库锁定文件的能力。由于我们使用二进制和不可合并的CAD文件，因此任何分布式版本控制系统的基于合并的工作流程在这里都无法工作。

3

Subversion是一个中央代码库。

虽然许多人希望有分布式代码库，以获得速度和多个副本的明显好处，但在某些情况下，中央代码库更为理想。例如，如果您有一些关键代码，不希望任何人访问，您可能不想将其放在Git下。许多公司希望保持他们的代码集中化，而（我猜）所有（严肃的）政府项目都在中央代码库下。

Subversion是传统智慧。

这意味着许多人（尤其是经理和老板）习惯于按版本编号并将开发视为沿时间“单线”进行硬编码。无意冒犯，但Git的自由并不容易接受。任何Git书籍的第一章都会告诉您要从头开始抹掉所有传统理念。

Subversion只有一种方式，没有其他方式。

SVN是一个版本控制系统。它只有一种方法来完成它的工作，每个人都是按照同样的方式进行操作。这使得从/到其他集中式VCS转换变得容易。Git甚至不是一个纯粹的VCS--它是一个文件系统，在不同情况下设置存储库的拓扑结构有许多种--而且没有任何标准。这使得选择变得更加困难。

其他优点包括：

SVN supports empty directories
SVN has better Windows support
SVN can check out/clone a sub-tree
SVN supports exclusive access control svn lock which is useful for hard-to-merge files
SVN supports binary files and large files more easily (and doesn't require copying old versions everywhere).
Adding a commit involves considerably fewer steps since there isn't any pull/push and your local changes are always implicitly rebased on svn update.

我看到这条信息并且同意它。对于那些新手来说，如果你用git的时候不小心触碰到一些东西，他们会非常生气。在git或github中，我不能信任ssh密钥等一些安全性还有待改进的方面。

2
我认为在Git中，你可以做几乎所有有意义的事情，甚至比Subversion还要多。这不应该成为你的担忧。然而，它们都很受欢迎，值得你关注，尤其是如果你从事开源编程。
我认为学习Git会更难一些，但一旦你掌握了它，人们通常会上瘾，认为其他SCMs不如它。Git对分布式支持非常好（还有其他工具，但Git可能是最广泛使用的），这对于管理源代码以外的其他任务非常有用。Git可以被认为是一个强大的ZIP工具，可以快速部署以跟踪一般文件系统变更，并以高效的方式在主机之间复制变更。
在Windows上，Git存在一些问题：
  • 许多实现中使用Unicode文件名支持存在漏洞。这方面的改进越来越多，但仍然是一个问题。
  • Windows上的资源管理器插件并不太好用。我发现使用命令行版本更容易。
但我认为Git具有而SVN没有的一些优点。在SVN中没有显式支持分支是一个重要的问题——Git实现非常好，可以让你在不考虑分支的情况下创建分支。能够离线工作也是一个主要的优势。
2
SVN在通过互联网处理多TB存储库方面非常实用。
从技术上讲，Git也可以处理，但是通过互联网克隆整个多TB存储库...嗯 - 我更喜欢在得到存储库的URL后的同一天开始工作，而不是10天之后。
注意：将整个内容分割成多个存储库的策略并不总是有效。如果我们作为游戏开发团队有一个包含源代码和资源的多TB游戏存储库（同时需要#1和#2来获取资源），我们肯定需要从一个单一的存储库构建我们的游戏（否则整个过程变得无法复制，没有多个存储库引用是件坏事）。
2. SVN可以锁定文件，对于不可合并的二进制文件（比如合并JPEG）来说，这通常是一件好事。
3. 使用SVN，您拥有一个单调的修订版本（因此修订版本357始终比修订版本350更新）。虽然相对较小，但这非常方便。
4. SVN可以以非整个仓库的粒度限制读取权限。
5. 对Git的一点抱怨：SVN可以处理合并的还原，而无需通过反直觉的方式重新引入一些被还原的更改（有关详细信息，请参阅Rollback a Git merge）。
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接