我们最终可以在企业软件中转向 DVCS 吗?SVN 仍然是开发的“必备"吗? [英] Can we finally move to DVCS in Corporate Software? Is SVN still a 'must have' for development?

问题描述

Git/Mercurial 变得越来越流行.我看过很多文章将 SVN 与 Git/Mercurial 进行比较，但我想知道是否真的有任何理由仍然使用 SVN.现在似乎有很多适用于 Git/Mercurial 的工具应该有助于扩大其企业采用率.

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.

还有什么理由继续使用 SVN?Mercurial/Git 终于准备好被企业采用了吗?

Are there any reasons to still use SVN? Is Mercurial/Git finally ready for corporate adoption?

推荐答案

一方面，SVN 集成(与 IDE、框架、wikis 等)非常成熟，以及它的 GUI 和代码浏览器(甚至尽管像 Git 和 Mercurial 这样的 DVCS 每天都在进步).

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).

另一方面，在企业环境中引入 DVCS 仍然不是一项简单的任务:

On the other hand, introducing a DVCS in an Enterprise environment is still not a trivial task:

• 有些要求不容易满足(就安全和访问控制、管理和访问限制)
• DVCS 范式更难理解，有很多利弊.
• 您确实需要利用其众多工作流，而不是依赖 SVN 集中式工作流.
• 从 CVCS 过渡到 DVCS 很困难

• Some requirements are not easily met (in terms of security and access control, administration and restriction of access)
• The DVCS paradigm is more complex to understand, with lots of pros and cons.
• You really need to leverage its many workflows instead of relying on the SVN centralized one.
• The transition from CVCS to DVCS is difficult

明确地说，使用DVCS 可能是一个非常有效的选择:

• 对于新项目，其中开发人员不受遗留工具或流程的束缚
• 尤其是当开发人员的地理位置不同时(通常是开源开发的情况，这就是为什么 DVCS 主要在那里使用的原因).

• for a new project, where the developers are not tied with legacy tools or processes
• especially when the developers are not geographically located in the same place (often the case with open-source development, which is why DVCS are mainly used there).

StackOverflow(不是开源项目)正在使用 Mercurial(请参阅 HgInit，由 Joel Spolsky 编写).
他们从 SVN 迁移到 DVCS:

StackOverflow (not an open source project) is using Mercurial (see HgInit, written by Joel Spolsky).
They migrated from SVN to a DVCS:

• 部分原因是他们的开发人员现在遍布世界各地(！)

• 还因为 DVCS 的合并功能比 SVN 先进得多.
  (他们需要在 SO 站点、StackExchange 站点 V1 和 V2、Area 51 之间维护许多并行的、略有不同的代码库版本……)
  请参阅DVCS 和 CVCS 之间的区别", 或 "什么是Mercurial 或 git 在分支/合并方面优于 svn?".

对于企业环境(我所在的地方)，任何形式的转变都不是微不足道的，因为它必须是:

For a corporate environment (where I am), any transition of any kind is not trivial, because it need to be:

• 资助(钱，即使工具是免费的)
• 支持(这意味着拥有具有适当能力的合适人员)
• 集成(与现有的旧工具、GUI、IDE 之类的 Visual Studio 或许多其他工具......)
• 管理(就公共服务器而言，即使是 DVCS)
• 已记录(特别是对于拥有 CVCS 之类的 SVN 背景的用户)

• funded (money, even if the tools are free)
• supported (that means having the right people with the right competences)
• integrated (with existing legacy tools, GUIs, IDEs like a Visual Studio or many others, ...)
• administrated (in term of common servers, even for a DVCS)
• documented (especially for users coming with a CVCS like SVN background)

因此 DVCS 在企业环境中也非常有用:
(参见Git 的企业采用率?"或企业中基于 Git 的源代码控制:建议的工具和实践?".)
它(即使对于新项目)并不像在较小的结构或开源环境中那样容易部署.

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.

这篇关于我们最终可以在企业软件中转向 DVCS 吗?SVN 仍然是开发的“必备"吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！