我使用 Subversion 几年了，相比于 SourceSafe，我更喜欢 Subversion。加上 TortoiseSVN，我实在想象不出还有什么更好的。
然而，越来越多的开发人员声称 Subversion 存在问题，我们应该转向新型分布式版本控制系统，例如 Git。
Git 如何改进 Subversion?
30个回答
8
David Richards谈Subversion / GIT的WANdisco博客
GIT的出现带来了一种DVCS原教旨主义——“吉特派”，他们认为除了GIT以外的任何东西都是垃圾。吉特派似乎认为软件工程只在自己的岛上进行，经常忘记大多数组织没有专门雇用高级软件工程师。虽然这没问题，但这并不是市场的想法，我很乐意证明：上次查看时，GIT市场份额不到3%，而Subversion拥有约500万用户和约一半的整个市场。
我们发现的问题是，吉特派在攻击Subversion。例如“Subversion太[慢/烂/限制太多/闻起来不好/面对我笑/……]，现在我使用GIT，[我的生活中一切工作正常/我的妻子怀孕了/我尝试30年后找到了女朋友/我在21点游戏中连赢六次]”。你得到了画面。
- Elaine Murphy
4
1请注意，David Richards可能是客观的：他制作的产品基于Subversion（或Subversion思想），因此他自然会支持Subversion并反对Git。 - Jakub Narębski
2具有讽刺意味的是，Git 的创建正是因为软件工程不会孤立无援。这句话很愚蠢。 - Ben Collins
虽然我使用git，但我也很乐意使用像Mercurial这样的任何好的分布式版本控制系统。DVCS概念需要时间才能获得普及，现在我看到许多开源项目已经转向git。 - Benbob
通过将svn的批评者描绘成原教旨主义者，大卫回避了一个根本问题：子版本控制架构是一条死胡同。并不是说git是版本控制系统的终极解决方案，它也有自己的缺点，但是git、mercurial、darcs和许多其他版本控制系统都具有更加优雅的仓库模型。由于目录等于分支模型使得真正的进展变得不可能，因此Subversion永远无法实现合并工作。像大卫公司这样的企业可以不断地给猪涂抹更多口红，但是svn必然会越来越落后于技术发展的最前沿。 - gtd
8
SubVersion有一件让我不爽的事情，那就是它在项目的每个目录中都放置了自己的文件夹，而git只在根目录中放置一个。虽然这不是什么大问题，但像这样的小细节会累积起来。
当然，SubVersion有Tortoise，这通常非常好用。
- swilliams
1
5很快，可能在v1.7版本中，.svn目录将不再存在。 - gbjbaanb
7
Git也使分支和合并变得非常容易。Subversion 1.5刚刚添加了合并跟踪，但Git仍然更好。使用Git分支非常快速和廉价。这使得为每个新功能创建一个分支更加可行。哦，而且与Subversion相比，Git存储库的存储空间非常高效。
- ejunker
6
这一切都关乎使用的便捷性/完成某事所需的步骤。
如果我在我的PC /笔记本电脑上开发单个项目，那么git更好，因为它设置和使用起来要容易得多。您不需要服务器，也不需要在合并时不断输入存储库URL。
如果只有两个人，我会说git也更容易，因为您可以相互推送和拉取。
不过，一旦超过两个人，我会选择subversion，因为此时您需要设置一个“专用”服务器或位置。
使用git和SVN同样可以做到这一点，但是，git的好处被需要与中央服务器同步执行额外步骤的需要所抵消。在SVN中，您只需提交即可。在git中，您必须进行git commit，然后进行git push。由于您最终会频繁地执行此操作，因此这个额外的步骤会变得很烦人。
SVN还具有更好的GUI工具，但是git生态系统似乎正在迅速赶上，因此从长远来看，我不会担心这个问题。
- Orion Edwards
4
11在 Git 中将提交与发布分开，我认为是一种优势而不是劣势。 - Jakub Narębski
好的，那么你认为在以下情况下 SVN 的“易用性/所需步骤”如何：
- 为实验创建主题分支
- 将此分支合并到另一个分支中
- 将文件中编辑的内容拆分为较小的提交
- 快速检出主分支以进行小修复
“用于实验的主题分支”这个参数经常被用来支持git，但说实话，在subversion或其他非分布式版本控制系统中，我从未见过有人真正使用它。也许这很重要，我们都错过了什么，但从我所见，99%的开发人员（包括我自己）不关心主题分支，因为他们从未使用过！-你不能错过你从未拥有过的东西:-)。我认为，如果分布式版本控制系统的人们要提出“主题分支”作为一个特性，他们必须首先说服每个人这些东西实际上是有用的。 - Orion Edwards
“将编辑的内容分成更小的提交”在理论上听起来很不错。但是，在过去的三年中，我从未想过“哦，我希望我能做到这一点”，甚至我都难以想象可能需要这个功能的假设情况...许多Git / DVCS倡导者只是说“我们有X，而X非常棒”，而其他人则坐在那里想知道他们为什么需要X。 - Orion Edwards
6
Easy Git有一个很好的页面，比较了Git和SVN的实际用法，这将让你了解Git相对于SVN可以做哪些事情（或更容易地完成哪些事情）。 （从技术上讲，这是基于Easy Git，它是在Git之上的轻量级包装。）
- Pat Notz
5
我喜欢Git，因为它实际上帮助中大型团队的开发人员进行沟通。作为分布式版本控制系统，通过其推/拉系统，它帮助开发人员创建源代码生态系统，有助于管理在单个项目上工作的大量开发人员。
例如，假设您信任5名开发人员，并且仅从他们的存储库中拉取代码。每个开发人员都有自己的信任网络，从中拉取代码。因此，开发基于开发社区共享代码责任的信任框架。
当然，还有其他好处，在其他答案中已经提到了。
例如，假设您信任5名开发人员，并且仅从他们的存储库中拉取代码。每个开发人员都有自己的信任网络，从中拉取代码。因此，开发基于开发社区共享代码责任的信任框架。
当然，还有其他好处，在其他答案中已经提到了。
- Mozammel
5
Git和DVCS（分布式版本控制系统）非常适合独立编码的开发人员，因为每个人都有自己的分支。但是，如果你需要别人的更改，她必须将更改提交到她的本地仓库，然后将该更改集推送给你或者你必须从她那里拉取。
我个人认为，如果你像进行集中式发布这样的操作，则DVCS也会使QA和发布管理变得更加困难。某人必须负责从其他所有开发人员的存储库进行推送/拉取，解决在初始提交时已经解决的任何冲突，然后进行构建，并要求所有其他开发人员重新同步他们的存储库。
当然，所有这些都可以通过人工流程来解决；DVCS只是为了提供一些新的便利而打破了集中式版本控制所修复的问题。
我个人认为，如果你像进行集中式发布这样的操作，则DVCS也会使QA和发布管理变得更加困难。某人必须负责从其他所有开发人员的存储库进行推送/拉取，解决在初始提交时已经解决的任何冲突，然后进行构建，并要求所有其他开发人员重新同步他们的存储库。
当然，所有这些都可以通过人工流程来解决；DVCS只是为了提供一些新的便利而打破了集中式版本控制所修复的问题。
- jaredg
1
1实际上，如果你看一下Linux内核或Git项目本身是如何管理的，你会发现Git非常适合“单个维护者”（或维护者+助手）工作流程，使用一个中央共识仓库。它使得临时切换到其他人作为维护者变得容易。 - Jakub Narębski
4
我认为Subversion还不错，直到你开始合并或进行任何复杂操作，或者进行任何Subversion认为是复杂的操作（例如查询哪些分支与特定文件搞乱了，变更实际来自哪里，检测复制和粘贴等）...
我不同意获胜答案，说GIT的主要优点是离线工作-当然很有用，但对于我的用例来说更像是额外的。SVK也可以离线工作，但对我来说没有疑问应该投入时间学习哪一个）。
只是它非常强大、快速和易用（是的，在这个意义上：用户友好）。
有关合并故事的更多细节，请参见： 使用git-svn（或类似工具）仅用于帮助svn合并？
我不同意获胜答案，说GIT的主要优点是离线工作-当然很有用，但对于我的用例来说更像是额外的。SVK也可以离线工作，但对我来说没有疑问应该投入时间学习哪一个）。
只是它非常强大、快速和易用（是的，在这个意义上：用户友好）。
有关合并故事的更多细节，请参见： 使用git-svn（或类似工具）仅用于帮助svn合并？
- inger
4
有一些答案已经提到了这些问题，但我想明确两点：
1）选择性提交的能力（例如git add --patch）。如果您的工作目录包含多个不属于同一个逻辑更改的更改，则Git非常容易使提交仅包括部分更改。而在Subversion中，这很难。
2）在不公开更改的情况下进行提交的能力。在Subversion中，任何提交都是立即公开的，因此无法撤销。这极大地限制了开发人员“早期提交，经常提交”的能力。
Git不仅是版本控制系统，还是开发补丁的工具。而Subversion只是版本控制系统。
- William Pursell
3
4
- 如果你使用的是TortoiseSVN，AnkhSVN等工具，那么选择要提交的有更改的文件非常容易（微不足道）。
- 如果你不想让其他开发人员获取你的代码，可以创建一个分支，在准备好后再合并，这并不难。
不可撤销？好的，你可以反向合并有问题的提交，这样仓库就回到了之前的状态。但是你说得对，它已经被记录了。但这是好事还是坏事呢？我猜这要视情况而定... - schoetbi
@schoetbi 不，存储库的头部与之前一样。现在存储库本身包含两个提交，而如果它们都不存在会更好。这是额外的杂乱无章，当您查看日志时会减慢速度。当然，这也可能发生在git中，特别是如果一些开发人员习惯于立即提交后推送。但在git中更容易避免这种情况。 - Tyler
3
我非常喜欢在Git中管理本地源代码分支，而不会影响中央仓库。在许多情况下，我会从Subversion服务器检出代码并运行本地Git存储库以实现此目的。初始化Git存储库也很棒，因为它不会在整个文件系统中散布一堆烦人的.svn文件夹。
就Windows工具支持而言，TortoiseGit可以很好地处理基础功能，但除非我想查看日志，否则我仍然更喜欢使用命令行。我真的很喜欢Tortoise{Git|SVN}在阅读提交日志时提供的帮助。
就Windows工具支持而言，TortoiseGit可以很好地处理基础功能，但除非我想查看日志，否则我仍然更喜欢使用命令行。我真的很喜欢Tortoise{Git|SVN}在阅读提交日志时提供的帮助。
- Matt Hulse
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接