代码之家  ›  专栏  ›  技术社区  ›  Will Robertson

为什么分布式源代码管理被认为更难?

  •  12
  • Will Robertson  · 技术社区  · 18 年前

    人们向新来者推荐SVN进行源代码管理似乎很常见(至少在这里是这样),因为它比分布式选项更容易实现。作为SVN的一个非常随意的用户,在我的许多项目切换到Git之前,我发现情况并非如此。

    它是概念上的 更容易的 设置DCV存储库 git init (或以两者中的任何一个为准),在SVN的情况下无需设置外部存储库。

    SVN、Git、Mercurial和Bazaar之间的基本功能都使用基本相同的命令来提交、查看差异等。这就是新来的人真正要做的。

    Git要求在提交之前显式添加更改的方式与SVN的“提交所有内容”策略相比,在概念上是简单的,除非我弄错了,否则在使用Mercurial或Bazaar时甚至都不是问题。

    那么为什么SVN被认为更容易呢?我认为这根本不是真的。

    9 回复  |  直到 16 年前
        1
  •  7
  •   Soraz Krishnendu    18 年前

    分布式版本控制系统是一件很好的事情(tm),但是我发现采用的主要障碍是教育用户新的SCM提供的新可能性。

    这再加上经常缺乏光泽的UI工具(半成品的乌龟式实现等),让许多同事看了一眼空白,因为他们早就为一个好的UI工具预见了命令行。

    而且,对于像cvs这样的工具,我发现人们不喜欢分支和合并,因为他们真的不想一整天都在做三种方式的合并,通常不确定哪种方式是正确的合并。

    我的观点是:首先告诉人们他们得到了什么(不仅仅是“嘿,看这个新的酷玩具”),然后让他们准备好使用命令行是一种方式,频繁的持续时间分支是一件好事。

    许多系统(如mercurial)都有完整的补丁队列系统,这意味着从持续集成的角度来看, 知道 任何投入生产的产品都已经过质量保证部门的批准。像这样的事情很难对cvs或svn进行正确处理。

    使用Mercurial,人们将拥有用于当前工作的私有存储库,所有开发人员在服务器上共享一个开发人员树。CI系统监视开发人员树,并提取所有更改、构建和执行单元测试。如果一切都通过了,它会将更改传播到一个测试树中,在该树中为QA人员构建一个可交付结果。添加的每个变更集都会获得一个标记。当QA认为一个特性是完整的时,他们用这个令牌注释测试树,然后相关的变更集自动传播到生产树。

    使用这种方法,您将永远不会手工向生产分支或测试分支提交任何东西。相反,代码的状态和QA的签字决定了生产部门的内容,

        2
  •  8
  •   Mecki    18 年前

    如果您只为自己使用版本控制,那么SVN可能更难,因为设置更难。但是,如果您希望通过Web与多个开发人员合作,则服务器端控件具有以下优点:

    • 您有一个中心位置,它始终具有最先进的官方源,即SVN服务器。
    • 由于每个人都将自己的更改合并到一个中央服务器上,因此冲突和手动修复冲突要少得多。
    • 你可以集中控制源头
    • 您有一个正式的修订号,而不是修订散列,在所有开发人员中都是相同的,并显示正式的进度(它是一个递增的数字,与散列不同,散列只是一个身份指纹,因此您可以通过这个数字看到哪个代码是新的或旧的
        3
  •  6
  •   Ben Hoffstein    18 年前

    我认为,从概念上来说,考虑一个集中的存储库(其中每个开发人员提交自己的工作,而不是整个存储库的多个副本)要简单得多,这些副本都不能代表“事实”。由于大多数开发人员都熟悉客户机-服务器模型和后端数据库的概念,这是一个自然的概念。

    当然,分布式源代码控制系统的强大之处在于,它们不必遵循这个模型,但对于新用户来说,它似乎更容易掌握。

        4
  •  4
  •   Community Mohan Dere    9 年前

    SVN强制一条工作线。你要么承诺,要么不承诺。有着相似的经历,我觉得hg或git并不难用,但是,我在一个团队中工作,这个团队似乎发现使用它们会带来噩梦。

    自动分支的整个概念,多个头部,什么时候和什么时候不合并完全回避他们,更不用说他们有困难打破“承诺/结帐与$somecore”的心态,这导致完全混淆,当他们看到推之间的2个签出副本。

    (有一段时间出现了一个问题,有人反复合并了2个分支,因为他们无法理解这个概念,所以不应该合并。)

    然而,同样的人谁与分布式SCM有问题,导致我问 this question

    编辑/注释 我注意到,Mercurials与Git的最大区别在于,Mercurial的推/拉默认行为与Git的推-全/Git拉-全一样,它可以传播私有分支并增加大量混乱(特别是当新分支出现时,Mercurial会恐惧地冻结并询问如何处理)它不只是继续卡车运输),以及Mac上的默认合并/冲突解决工具只是盲目地破坏一组更改。

        5
  •  2
  •   David Raznick    18 年前

    我认为SVN的工具集要广泛得多,所以您可以坐下来教人们(Tortoissesvn、Rapidsvn等),即使他们对存储库的工作方式没有太多概念上的了解。它也相对容易让SVN为您托管(例如,使用Trac),而不需要知道任何事情。分布式的还没有这方面的支持,我相信当他们这样做的时候,他们的观点会改变。

        6
  •  1
  •   Aaron Maenpaa    18 年前

    我认为用dvc建立一个存储库是 几乎 更容易,但 概念上 更努力。毕竟,有了一个集中式的VCS,用户就不会建立自己的存储库,他们只需要在assemble上创建一个帐户或为他们设置repo。

        7
  •  1
  •   Borek Bernard    18 年前

    dvcs目前缺乏良好的桌面客户端。尽管大多数人都这么说,版本控制系统可能很难正确使用,所以一个好的桌面客户端可以真正帮助-在这里,Tortoissesvn很出色。

        8
  •  0
  •   pablo    17 年前

    我们努力使它尽可能容易在编纂,但它总是有点难解释,当然,这取决于观众。

    对于OSS项目和小团队来说,特别是那些在笔记本电脑上工作,四处走动,在家里工作,有时在飞机上工作,等等,这非常容易。但是,每当您与公司/企业交谈时,他们都会对它的多站点角色感到兴奋,但对于第一眼看到的分布式角色就不那么兴奋了。这完全取决于该团队是否拥有大多数高级开发人员。

        9
  •  0
  •   jammycakes    16 年前

    它是 poor marketing 很简单。太多的dvc介绍集中在命令行上并说“哇,这不是很好吗,你只需输入hg merge”就可以进行合并,完全忽略了许多人(尤其是在windows环境中)害怕命令行的事实。是的,乔尔·斯波斯基,我在看你自己的 hginit.com 这里——我们需要一个乌龟版的!

    也许两年前,他们的图形用户界面实现很差,但最近却突飞猛进。TortoiseHg现在使用的是1.0版,虽然它可能不需要在视觉上写任何东西,但它非常坚固、稳定并且易于使用。TortoiseGit也是坚如磐石的,它在提取Git命令行的所有复杂性方面做得很好。