我们最终可以转移到企业软件中的DVCS吗？ SVN仍然是发展的必须品吗？ [英] Can we finally move to DVCS in Corporate Software? Is SVN still a 'must have' for development?
问题描述
是否有任何理由仍然使用SVN？ Mercurial / Git最终准备好用于企业应用程序吗？一方面，SVN集成（使用IDE，框架，wiki， ...）是非常成熟的，以及它的GUI和代码浏览器（尽管像Git和Mercurial这样的DVCS每天都在发展）。另一方面，在Enterprise环境中引入DVCS仍然不是一项简单的任务：
- 一些要求不易实现（在安全性和访问控制，管理和访问限制方面）
- DVCS范式的理解更为复杂，有很多优点和缺点。 你真的需要来利用其许多工作流，而不是依赖SVN集中式工作流。
- 从CVCS到DVCS的过渡很困难
<要明确，使用 DVCS可以是一个非常有效的选择：
- 对于新项目，其中开发人员不与旧版工具或流程绑定 特别是当开发人员地理位置不在同一地点（开源开发常常是这种情况，这就是为什么DVCS主要用于那里）。
StackOverflow（不是开源项目）正在使用Mercurial（请参阅他们从SVN迁移到DVCS：
- $部分原因在于他们的开发人员现在遍布全球（！）
-
，并且还因为DVCS的合并工具比SVN更先进。
（他们需要维护许多并行的略有不同版本的代码库，在SO站点之间，StackExchange站点V1和V2，区域51，...）
请参阅 DVCS和CVCS之间的差异，或者有什么好处Mercurial或git over svn进行分支/合并？。 -
对于
企业环境（我在哪里），任何类型的转换都不是微不足道的，因为它必须是：
- 资助（即使这些工具是免费的，也是钱）
- 支持具有正确能力的合适人员）
- 集成（使用现有的旧版工具，图形用户界面，IDE等Visual Studio或其他工具，...） >
- 管理（在常见服务器方面，即使是DVCS） 用户使用像SVN背景之类的CVCS）
$ b因此DVCS也可以非常在企业环境中很有用：
（请参阅 Git的企业采用率？ 或企业中基于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?
解决方案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:
- 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
Just to be clear, using a DVCS can be a very valid choice:
- 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 (not an open source project) is using Mercurial (see HgInit, written by Joel Spolsky).
They migrated from SVN to a DVCS:- in part because their developers are now all over the world(!)
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:
- 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)
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屋！
