我们最终可以在企业软件中转向 DVCS 吗？ SVN 仍然是“必须拥有”吗？为了发展？
Git/Mercurial 已经变得越来越流行。我看过很多比较 SVN 与 Git/Mercurial 的文章，但我想知道是否真的有任何理由仍然使用 SVN。现在似乎有很多适用于 Git/Mercurial 的工具，这应该有助于扩大其企业采用率。
还有什么理由继续使用 SVN 吗？ Mercurial/Git 最终准备好供企业采用了吗？
Git/Mercurial have been becoming more and more popular. I have seen plenty of articles comparing SVN with Git/Mercurial, but I am wondering if there is really any reason to still use SVN. It seems like there are plenty of tools for Git/Mercurial now which should help spread its corporate adoption.
Are there any reasons to still use SVN? Is Mercurial/Git finally ready for corporate adoption?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（11）
一方面，SVN 集成（与 IDE、框架、wiki 等）非常成熟，它的 GUI 和代码浏览器也非常成熟（尽管像 Git 和 Mercurial 这样的 DVCS 每天都在进步）。
另一方面，在企业环境中引入 DVCS 仍然不是一项简单的任务：
需要明确的是，使用DVCS 可能是一个非常有效的选择：
StackOverflow（不是开源项目）正在使用 Mercurial（请参阅 HgInit，由 Joel Spolsky 编写）。
他们从 SVN 迁移到 DVCS：
而且还因为 DVCS 的合并设施比 SVN 先进得多。
（他们需要在 SO 站点、StackExchange 站点 V1 和 V2、Area 51 之间维护许多并行且略有不同的代码库版本，...）
请参阅“DVCS 和 CVCS 之间的差异” ，或“什么是Mercurial 或 git 相对于 svn 在分支/合并方面有何优势？”。
对于公司环境（我所在的地方），任何类型的转变都不是微不足道的，因为它需要：
因此 DVCS 在企业环境中也非常有用：
（请参阅“Git 的企业采用率？”或“企业中基于 Git 的源代码控制：建议的工具和实践？“。）
它（即使对于新项目）根本不像在较小的结构或开源环境中那么容易安装到位。
On the one hand, SVN integration (with IDE, frameworks, wikis, ...) is very mature, as well as its GUIs and code browsers (even though DVCS like Git and Mercurial progress every day).
On the other hand, introducing a DVCS in an Enterprise environment is still not a trivial task:
Just to be clear, using a DVCS can be a very valid choice:
StackOverflow (not an open source project) is using Mercurial (see HgInit, written by Joel Spolsky).
They migrated from SVN to a DVCS:
and also because the merge facilities of a DVCS are much more advanced than in SVN.
(which they need to maintain many parallel slightly different versions of their code base, between SO sites, StackExchange sites V1 and V2, Area 51, ...)
See "differences between DVCS and CVCS", or "What are the benefits of Mercurial or git over svn for branching/merging?".
For a corporate environment (where I am), any transition of any kind is not trivial, because it need to be:
So DVCS can also be very useful in a corporate environment:
(See "Corporate adoption rate of Git?" or "Git-Based Source Control in the Enterprise: Suggested Tools and Practices?".)
It is (even for new projects) simply not as easily put in place than in a smaller structure or in open-source environments.
如果说有什么不同的话，那就是 Subversion 对于单个开发人员来说更糟糕（设置起来更麻烦）。
但继续使用 SVN 的一个很好的理由是惯性。如果 SVN 适合您的项目（或您的公司），则无需经历切换的痛苦。向每个人教授新工具（和新工作流程）可能会涉及一些培训成本，但没有真正的好处。
If anything, Subversion is worse for a single developer (more troublesome to setup).
But a good reason to keep using SVN is inertia. If SVN works fine for your project (or in your company), there is no need to go through the pains of switching over. There might be some training costs involved in teaching everyone the new tools (and new workflows), with no real benefits.
我认为 Subversion 对于媒体资产、Photoshop 文件、After Effects 合成等大型文件来说仍然比 Mercurial 和 Git 更好。我记得 Linus Torvalds 在 此 Google 技术讲座。 Mercurial 有一些扩展用于在存储库之外存储大文件。因此，在这种情况下，它们似乎都遭受了一些性能下降和/或其他问题。
另一方面，当前的 Blender Open Movie Project 正在使用 Subversion。我认为他们不会使用它来存储渲染的帧，因为每个渲染通道至少需要几千兆字节的数据。但尽管如此，尽管有所有 3D 场景、对象、装备、纹理和脚本，这仍然是一个包含许多大文件的大型存储库。
I think Subversion still works better than Mercurial and Git for large files like media assets, Photoshop files, After Effects composites, etc. I remember Linus Torvalds mentioning big files as one of the very few potential problems with Git in this Google Tech Talk. Mercurial has a few extensions for storing large files outside a repository. So it seems they both suffer some performance degradation and/or other issues in that scenario.
Subversion, on the other hand, is being used by the current Blender Open Movie Project. I don't think they use it to store the rendered frames, since that would be at least a few gigabytes of data for each render pass. But still, with all the 3d scenes, objects, rigs, textures, and scripts, that's still one big repository with many large files.
如果您已经使用了很长一段时间，我可以理解您可能继续使用 SVN 的原因。特别是在小公司或编码圈中，从 SVN 过渡到 git 或 Mercurial，当您可能不使用它们中任何更强大的功能时，可能会让您不愿意进行转换。正如 Thilo 所指出的，使用 SVN 的大公司将会发现这种变化是巨大的。
另外，我认为SVN仍然有它的地方，特别是在教学修订控制方面。但这是我个人在大学学习 SVN 和自学 git 的经历，所以我的观点对此并不客观。
话虽这么说，如果您从头开始创建存储库，我想不出您认为 SVN 绝对必要的任何条件。也许在处理遗留系统时。
或旧用户；）
I can see reasons where you might continue to use SVN if you had been using it for a long time. Especially in a small company or coding circle, the transition from SVN to either git or Mercurial, when you might not be using any of the more powerful features of them, might make you adverse to making the switch. As pointed out by Thilo, a large company using SVN is going to find that change monumental.
Also, I think SVN still has is places, particularly when it comes to teaching revision control. But that's taking from my own personal experience of learning SVN in university versus teaching myself git, so my opinions won't be objective on that.
That being said, if you were starting a repository from scratch, I can't think of any conditions where you might decide SVN is absolutely necessary. Perhaps when dealing with legacy systems.
or legacy users ;)
我不知道有什么偏爱集中式风险投资的内在原因，有很多外在因素，例如遗留系统、管理惯性、学习曲线等。DVCS
几乎证明了自己是“更好的”捕鼠器”。
I don't know of any intrinsic reasons to prefer centralized vcs, there are plenty of extrinsic factors like legacy systems, managerial inertia, learning curve, etc.
DVCS is pretty much demonstrating itself to be the "better mousetrap".
真正的问题不是 SVN 与 Git/Mercurial，而是分布式与集中式。在某些情况下，集中化可能会更好，例如需要严格控制和彻底日志记录的公司环境。
The real question isn't SVN vs. Git/Mercurial, it's distributed vs. centralized. Centralized can be better in some situations such as a corporate environment where you need tight control and thorough logging.
我们使用 subversion 作为数据存储，这对于合并来说并不简单（我们进行硬件开发，设计文件是未记录的二进制格式）。 SVN 的优点是可以对文件设置锁定，因此只有一名开发人员可以处理一个文件，并且在编辑之前还必须签出最新的文件。
We use subversion as storage for data, which is non trivial to merge (we do hardware development, and the design files are a undocumented binary format). SVN has the advantage that you can set locks on files, so only one developer can work on a file, and is also forced to check out the newest file before editing.
当中心化范式理想时，颠覆就是理想的。
其中一种情况是在处理论文时。保留一份每个人都可以从中提取的主副本更有意义。我们不想创建分支或标签。我们只是想跟踪谁进行了更改，然后传播给所有作者。
Subversion is ideal when the centralized paradigm is ideal.
One such situation is when working on papers. It makes much more sense just to keep one master copy that everyone pulls from. We don't want to create branches or tags. We just want to keep track of who makes a change and then propagate to all authors.
Subversion 与 Apache 集成得非常好！
Subversion integrates very well with Apache!
您可以使用 Git 和 Hg 作为 SVN 客户端。这意味着您可以两全其美。
但是，您不能使用 SVN 作为 Git 或 Hg 的客户端。
在许多方面，理想的情况是一个中央 SVN 存储库，用户可以使用他们喜欢的任何 DVCS 作为客户端。
对于很多人来说，SVN 更容易学习和使用，而且它的工具也更加成熟。
You can use both Git and Hg as SVN clients. That means you can have the best of both worlds.
You cannot however use SVN as a client for either Git or Hg.
In many ways the ideal case is a central SVN repository with users using whichever DVCS they like as a client.
SVN is much easier to learn and use for many people, and its tooling is far more mature.
我的回答基于一些假设：
其次，DVCS 被认为是比 Subversion 更好、更强大的工具。过去在 Stack Overflow 上对此进行了很多讨论，其他答案也表明大多数人都认为 DVCS 是“更好的捕鼠器”。我觉得没有必要证明这一点；您可以仔细阅读此处已发布的链接/类似问题。当然，并不是每一个 DVCS 在各个方面都比 Subversion 更好，但我相信像 Mercurial、git 等领先的 DVCS 几乎在各个方面都比 Subversion 更好。
因此，按照我的逻辑，如果您要选择最适合这项工作的工具，而 Subversion 是一个较差的工具，则不应再使用 Subversion。这并不意味着我们会立即在全球范围内得到采用，但我认为，如果您相信使用最好的工具来完成工作，那么所有组织都应该计划迁移到动态控制系统。当然，很多人不会，我预计人们会继续使用 Subversion 很长一段时间。
My answer is based on a few assumptions:
Secondly, that a DVCS is considered a better, more powerful tool than Subversion. It has been discussed a lot on Stack Overflow in the past, and other answers have chimed in that most people agree that DVCS is "the better mousetrap." I don't feel it's necessary to prove this point; you can peruse the linked/similar questions already posted here. Of course, not every single DVCS will be better than Subversion in every aspect, but I believe that leading DVCS's like Mercurial, git, etc are better than Subversion is nearly every aspect.
So by my logic, if you are going to choose the best tool for the job, and Subversion is an inferior tool, Subversion should no longer be used. That doesn't mean we'll see instant, worldwide adoption, but it is my contention that--if you believe in using the best tool for the job--all organizations should plan to move to a DVCS. Of course, many will not, and I expect people will continue to use Subversion for a long time.