公司软件开发中是否可以最终使用分布式版本控制系统（DVCS）？SVN对于开发仍然是必备的吗？
31
- Conceited Code
15
3这个问题在https://dev59.com/anVD5IYBdhLWcg3wXaid上被广泛讨论。 - wuputah
1这个应该是社区维基的...但我认为它并不是那么主观，无法提供一个好的答案（像VonC的答案一样）。 - Cascabel
2@george 这个问题怎么会是主观的或有争议的呢？在你修改这个问题之前，它只是问是否有任何有效的理由为什么有人会使用SVN。我没有要求任何意见或者哪一个更好。只是Git/Hg似乎正在取代SVN，是否有任何理由我应该使用SVN。我不是在询问“必须拥有”或企业软件。如果有什么争议的话，那就是人们试图关闭这个问题，因为它具有争议性。所以我们基本上在争论是否有争议，这非常幼稚。 - Conceited Code
3@Conceited，George绝对是正确的。你的标题是一个修辞问句。当你问“是否仍有使用???的理由”时，你暗示世界已经进步了，应该避免使用???. 如果你不想让它具有主观性（或者可能引起争议），你应该用这样的措辞来提问：“在选择新的版本控制系统时，我应该考虑哪些理由来选择集中化版本控制系统而不是分布式版本控制系统？” - Ash
2感谢@VonC提供的精彩答案。我仍然无法相信有些人认为这是主观的或争论的。我想要的只是像@VonC那样的答案，而在这个过程中问题被关闭和重新打开了两次才得到了答案。 - Conceited Code
显示剩余10条评论
11个回答
102
一方面，SVN的集成（与IDE、框架、维基等）非常成熟，其GUI和代码浏览器也很成熟（尽管像Git和Mercurial这样的DVCS每天都在进步）。
另一方面，在企业环境中引入DVCS仍然不是一个简单的任务：
另一方面，在企业环境中引入DVCS仍然不是一个简单的任务：
- 某些要求很难满足（涉及安全和访问控制、管理和访问限制）
- DVCS范例更加复杂, 有很多优缺点。
- 你真的需要利用其许多工作流程而不是依赖于SVN的集中式工作流程。
- 从CVCS到DVCS的过渡很困难
明确一点，使用DVCS可以是一个非常有效的选择:
- 对于新项目，其中开发人员没有与传统工具或流程绑定
- 特别是当开发人员不在同一地方时（通常是开源开发的情况，这就是为什么DVCS主要在那里使用的原因）。
StackOverflow（不是开源项目）正在使用Mercurial（请参见HgInit，由Joel Spolsky编写）。
他们从SVN迁移到了DVCS：
- 部分原因是他们的开发者现在遍布全球！
还有，DVCS的合并工具比SVN更加先进。
（他们需要维护许多平行略有不同版本的代码库，在SO网站、StackExchange网站V1和V2、Area 51等之间）
请参阅“DVCS和CVCS之间的区别”或“Mercurial或git相对于svn在分支/合并方面的好处是什么？”。对于企业环境（我所在的地方），任何形式的转换都不是轻松的，因为它需要：
- 资金支持（即使工具是免费的也需要资金）
- 支持（这意味着必须拥有具备正确能力的人员）
- 集成（与现有的遗留工具、GUI、IDE如Visual Studio或其他许多工具集成）
- 管理（即使是DVCS，也需要公共服务器进行管理）
- 记录（特别是针对来自SVN背景的用户）
因此，分布式版本控制系统在企业环境中也非常有用：
（请参见“Git在企业中的采用率？”或“企业中基于Git的源代码控制：建议的工具和实践方法？”。）
即使对于新项目，它的实施也不像在较小的结构或开源环境中那样容易。
- VonC
3
4这些链接实际上指出了如何克服大多数人[认为他们]需要坚持使用Subversion的原因。链接文本有点令人困惑，但请查看每个链接以了解更多关于每个问题的信息。 - wuputah
16根据我的经验，目前分布式版本控制系统（DVCS）的图形用户界面非常不成熟。基本上，SVN的GUI已经达到了类似于OSX的水平，而DVCS的GUI则好像被困在Windows for Workgroups 3.11模式中... 对于我这样的从令人惊叹的SVN GUI切换到所谓的DVCS艺术状态的GUI菜鸟来说，真的非常痛苦。如果你是一个命令行高手，那么这不是问题，但对于像我这样的GUI娘炮来说，这真是一种折磨。 - Jeff Atwood
4@Jeff: 就 IDE 集成而言，EGit 已经到位了（Eclipse 致力于此：所有项目都在一年前从 CVS 转向 Git），而 Git Extension 也更好用（包括了 Visual Studio 的集成）。TortoiseGit 则通过类似 Tortoise 的 shell 集成来帮助之前使用 SVN 的用户。是的，gitk 和 git-gui 这些基于 tcl-tk 的工具很糟糕，但并非唯一的替代品。Mac 上的 GitX 也不错。 - VonC
22
对于单个开发者而言，使用Subversion是否更好呢？
实际上，对于单个开发者而言，Subversion 更繁琐（设置更麻烦）。
但是继续使用 SVN 的一个好理由是惯性。如果 SVN 对你的项目（或公司）运行良好，则没有必要经历切换的痛苦。可能需要一些培训成本来教导大家新工具（以及新的工作流程），却没有真正的好处。
- Thilo
5
4我同意 @Thilo 的观点。SVN 没有任何严重的问题需要紧急转换。对于新项目，您可以选择 git。否则，我公司已经使用 SVN(r8000+) 三年，一切都在掌控之中。我试图遵循“不修复没有问题的东西”的原则。 - thevikas
2没有冒犯的意思，Thilo，但那听起来很像“一直以来我们都是这样做的……”这本身从来不是一个好理由。我同意转换会有成本和痛苦，也同意你不会轻率地做出改变（跟风），但我也认为你不能仅凭经验说你会承担所有成本而没有真正的好处，需要进行适当的成本效益分析。分布式版本控制确实有真正的好处，真正的问题是这些好处是否足以抵消成本？ - Paul
2@Paul：最重要的是保留历史记录，保留关于发布了什么、如何到达目标等“机构知识”。拥有一个版本控制系统（并且使用良好的实践）对此至关重要，但使用哪个版本控制系统……则不那么重要。在考虑转向分布式版本控制系统时，您必须确定这样做的成本是否能在可容忍的时间内收回；如果需要20年才能收回成本，对于几乎所有项目来说，这仍然不值得。 - Donal Fellows
同意，这就是为什么我说你必须对成本和收益进行分析。 - Paul
3直到我真正开始使用Git（实际上是通过使用git-svn网关）我才意识到“转换”Git的好处。因为像私有提交、可重写的历史记录和补丁管理等新功能可以/应该彻底改变您的工作流程，以及您组织工作的方式。与一部信誉良好的老式诺基亚手机相比，智能手机的好处是什么？如果你只对基本通话感兴趣，那就没有任何好处。但是如果你想改变你的工作方式，智能手机会有很多好处。 - MarcH
12
我认为对于类似媒体资产、Photoshop文件、After Effects合成等大型文件，Subversion仍然比Mercurial和Git更好用。我记得Linus Torvalds在这个Google Tech Talk中提到Git的问题之一就是处理大文件的能力。Mercurial有一些扩展可以将大型文件存储在仓库之外。因此在这种情况下，它们两者都会出现一些性能下降和/或其他问题。
另一方面，当前的Blender Open Movie Project正在使用Subversion。我不认为他们用它来存储渲染后的帧，因为每次渲染通过至少需要几千兆字节的数据。但是，仍然存在许多大文件的一个大型仓库，包括所有的3D场景、对象、骨架、纹理和脚本。
- Mhmmd
11
如果你长期使用SVN，我可以理解你继续使用它的原因。特别是在小公司或编码圈子中，当你可能不使用它们更强大的功能时，从SVN转换到git或Mercurial可能会让你望而却步。正如Thilo所指出的，使用SVN的大型公司将会发现这种变化是巨大的。
此外，我认为SVN仍然有其优势，尤其是在教授版本控制方面。但这只是基于我在大学学习SVN和自学git的个人经验，所以我的观点并不客观。
话虽如此，如果你要从零开始建立一个存储库，我想不到任何情况下你会认为SVN是绝对必需的。也许在处理遗留系统时才需要。
或者遗留用户;)
- JBirch
8
1对于传统用法，使用-1，检出git-svn。您可以在客户端上使用git，将svn作为中央仓库，而不对传统基础设施进行任何更改。 - Paul
3@Paul：虽然 git-svn 是一个很酷的小工具，但它并不能带给你任何实际上的好处，而且为了获得更多功能，必须做出一些权衡。我认为 git-svn 没有比 SVN 更强大，而且比 Git 更受限制。遗留的基础设施仍然是相同的，现在你可以使用 Git 命令与它进行交互，但如果你已经在使用 SVN 并且它能胜任工作，那么为什么要把事情搞复杂呢？ - JBirch
git-svn 是一种完全解放的体验。最终，您可以在不污染或破坏 SVN 以及惹恼同事的风险下，自由地进行暂存、提交、取消提交、分支、变基、压缩等各种实验。git-svn 真的是首选的 SVN 客户端。 - MarcH
@JBirch 我在工作中使用过git-svn，它非常有用。我的公司选择了svn，因为这是一个保守的选择（他们行动缓慢），但总是提交到中央svn服务器的刻板和不灵活性让我感到疯狂。添加本地git层使事情变得更加容易处理，尽管git-svn是一个明显不完美的中介（特别是不断的rebase）。 - snogglethorpe
@snogglethorpe 我现在也处于同样的情况，我必须抵制使用git-svn。当我从这家企业公司的角度看待它时，我理解任何时候都需要对所有代码进行核算的重要性。虽然git-svn允许我更多地控制自己的操作，但却给我的雇主带来了更少的关于其操作库的确定性。我个人需要做的事情在SVN的范围内 - 我没有必要使用本地git层，因为我可以在SVN repo中创建一个分支并在不污染其他人的情况下使用它。我想我们有不同的需求/限制 :) - JBirch
显示剩余3条评论
9
我不知道有什么内在的理由支持集中式版本控制系统，但有许多外在因素影响，例如遗留系统、管理惯性、学习曲线等。
分布式版本控制系统正在证明自己是“更好的捕鼠器”。
- msw
8
真正的问题不是SVN vs. Git/Mercurial，而是分布式和集中式的区别。在某些情况下，如需要严格控制和完整日志记录的企业环境中，集中式可以更好。
- Adam Crume
1
4你可以将 Git 用作集中式版本控制系统（我们就是这样使用的），但我们也会利用其额外的功能。 - tamasd
7
我们使用Subversion作为数据存储，这是一个非常复杂的合并过程（我们进行硬件开发，设计文件是未经记录的二进制格式）。 SVN的优点是您可以在文件上设置锁定，因此只有一个开发人员可以处理文件，并且还被强制检查最新文件才能进行编辑。
- Rudi
6
当集中式范例适用时，Subversion是理想的选择。
其中一个适用情况是在撰写论文时。只需保留一份主要副本供所有人使用更为合理。我们不需要创建分支或标签。我们只需要跟踪谁进行了更改，然后传播给所有作者。
- carl
1
1我不会说“理想”，更多的是“永远需要的唯一模式”。在某些情况下是正确的。 - Jeff Atwood
3
Subversion（版本控制工具）与Apache（Web服务器）非常兼容！
- Docunext
3
您可以将Git和Hg作为SVN客户端使用。这意味着您可以拥有两全其美的效果。
但是，您不能将SVN用作Git或Hg的客户端。
在很多情况下，理想的情况是使用中央SVN存储库，并让用户使用他们喜欢的任何DVCS作为客户端。
对于许多人来说，学习和使用SVN要容易得多，而且它的工具成熟度更高。
但是，您不能将SVN用作Git或Hg的客户端。
在很多情况下，理想的情况是使用中央SVN存储库，并让用户使用他们喜欢的任何DVCS作为客户端。
对于许多人来说，学习和使用SVN要容易得多，而且它的工具成熟度更高。
- sylvanaar
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接