分布式版本控制系统能否存活?

时间:2010-04-01 15:51:45

标签: svn version-control dvcs

我个人是SVN爱好者,但我开始成为围绕DVCS的嗡嗡声的牺牲品。

SVN是免费的,经过时间考验,DVCS是新的SVN吗?

我也在寻找哪种DVCS服务器能赢得GIT或Mercurial?

5 个答案:

答案 0 :(得分:4)

我所知道的每个分布式版本控制系统也是免费的。分布式系统提供了许多好处,我认为真正的问题是传统系统是否能够生存。我对此的回答是否定的。

答案 1 :(得分:4)

哪个会赢,Git还是Mercurial?两者都会“赢”。

  • 它们在使用上非常相似。学习Git或Mercurial的人可以轻松地从一个切换到另一个,只需要学习如何以不同的方式说出一些命令。 (最大的区别在于高级用法)。

  • 它们具有互操作性。您可以在Mercurial和Git存储库之间推送数据,而不会丢失信息。

  • 没有真正令人信服的理由从Git切换到Mercurial,反之亦然。

  • 两者都不比另一个更受欢迎。 Google为“git dvcs”返回了494k的结果,为“mercurial dvcs”返回了342k的结果。 Bzr有173k,Darcs有51k。

答案 2 :(得分:2)

你可以看看维基上的优点和缺点

  • 的差异

    • 可能有许多“中央”存储库。
    • 来自不同存储库的代码基于信任网络合并,即历史价值或变更质量。
    • 中尉是项目成员,有权动态决定合并哪些分支。
    • 网络不涉及大多数操作。
    • 可以使用一组单独的“同步”操作来提交或接收远程存储库的更改。

[edit]

  • 优点

    • 即使未连接到网络,也允许用户高效工作
    • 由于不涉及网络,因此大多数操作都更快
    • 允许参与项目而无需项目部门的许可,因此可以说更好地培养精英文化[需要引证]而不是要求“提交者”身份
    • 允许私人工作,因此即使对于您不想发布的早期草稿,您也可以使用修订控制系统
    • 避免依赖单个物理机器。服务器磁盘崩溃是具有分布式版本控制的非事件
    • 仍允许集中控制项目的“发布版本”

[edit]

  • 缺点

    • DVCS的概念对于开发人员来说更难以掌握,因为他们需要更多地了解基础设施。
然而,最后我相信它将归结为公司使用什么。看看COBOL,它仍然在很多地方使用,即使它甚至已经教得那么多了。已经实施此项目的公司很可能会继续使用他们拥有的产品,而不是改变一切以适应新的炒作。 IMO。

答案 3 :(得分:2)

分布式源代码控制很棒,但它实际上取决于您正在处理的项目类型。大多数公司需要一个集中的存储库作为每个人都可以参考的点。因此,当你在寻找像GIT或Mercurial这样的工具时,它不是“分布式”,这对于一家大公司来说是重要的卖点(虽然因此有一些细节,但这不是最重要的事情)。它们的美妙之处在于它们使合并分支更容易。这使您能够更频繁,更有效地进行分支,并提供比“集中式”系统更多的中间步骤。是的,这主要是因为它们是在分布式模型中设计的,但并非完全如此。我个人喜欢GIT ......但我将它用于集中的“存储库”,因为它对业务有意义。

就自由而言,这不是一个真正的问题。大多数(如果不是全部)分布式源控制系统是免费的。只有时间会告诉谁“胜出”,但如果我不得不下注,我也不会说。有几十个单独的SCM都失败了,成千上万的公司都使用它们。

答案 4 :(得分:2)

我认为我们不会看到中型或大型公司很快就会离开集中式系统。大公司关心集中和控制。他们有治理和合规问题需要处理,他们需要集中管理。所以我认为你会继续看到企业中的集中式系统。

与此同时,DVCS很可能会主导开源生态系统。我们已经看到了最近Git和微软支持Mercurial在codeplex上的普及。

我个人希望看到一个组合。我认为用于跟踪“官方”存储库的集中式服务器将有助于企业环境,但是分布式工作副本允许为单个开发人员进行廉价分支和合并将非常有用。

我前几天专门针对Subversion撰写了这篇博文。我不确定我们有多大可能会看到这样的东西来自SVN团队,但我认为它可能非常强大。

http://www.sublimesvn.com/blog/2010/03/subversion-vision-conference-distributed-subversion-unlikel/