为什么分布式源代码控制被认为更难？

人们向新手推荐SVN来源控制似乎相当普遍(至少在这里),因为它比其中一个分布式选项"更容易".作为SVN的一个非常随意的用户,在为我的许多项目切换到Git之前,我发现根本不是这种情况.

概念上更容易设置DCVS存储库git init(或其中任何一个),而不必在SVN的情况下设置外部存储库.

SVN,Git,Mercurial,Bazaar之间的基本功能都使用基本相同的命令来提交,查看差异等.这真是一个新人真正要做的事情.

与SVN的"提交一切"政策相比,Git要求更改的方式在提交之前显式添加的微小差异在概念上很简单,除非我错了,否则在使用Mercurial或Bazaar时甚至都不是问题.

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

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

你有一个中心位置,它总是有最先进的官方来源,是SVN服务器

由于每个人总是将他的更改与中央服务器合并,因此碰撞的次数要少得多,手动修复的次数要少得多

您可以对源进行集中控制

您有一个正式的修订号而不是修订版哈希,在所有开发人员中都是相同的并且显示正式进度(这是一个向上计数的数字,不像哈希,它只是一个身份指纹,所以你可以看到哪个代码更新或者年龄较大,只是这个数字

分布式版本控制系统是A Very Good Thing(tm),但我发现采用的主要障碍是教育用户新的SCM给出的新可能性.

这与经常缺乏光彩的UI工具(半完成的乌龟实施等)相结合,给许多同事们留下了一个空白的目光,他们为了一个好的UI工具而长期以来一直在使用命令行.

此外,使用像CVS这样的工具,我发现人们厌恶分支和合并,因为他们真的不想被困一整天做三向合并,通常不确定哪个是合适的合并.

我的观点是:首先告诉人们他们获得了什么(不仅仅是"嘿,看看这个新酷玩具"),并准备他们使用命令行是要走的路,而频繁的恒定时间分支是一件好事. .

许多系统(如mercurial)都带有完整的补丁队列系统,这意味着从持续集成的角度来看,您知道生产中的任何内容都已经过QA批准.像这样的东西很难用CVS或SVN做好.

使用Mercurial,人们可以拥有当前工作的私有存储库,所有开发人员在服务器上共享开发人员树.CI系统监视开发人员树并提取所有更改,构建和执行单元测试.如果一切都通过,它会将更改传播到测试树,从而为QA人员构建可交付成果.添加的每个变更集都会获得一个令牌.当QA认为某个功能完成时,他们会使用此令牌注释测试树,然后相关的更改集会自动传播到生产树.

使用这种方法,您永远不会手动向生产分支或测试分支提交任何内容.而是代码的状态和QA的签名决定了生产分支的内容,

我认为在概念上更容易想到一个集中式存储库,其中每个开发人员提交他的工作与整个存储库的多个副本,其中没有一个代表"真相".由于大多数开发人员都熟悉客户端 - 服务器模型和后端数据库的概念,因此这是一个自然概念.

当然,分布式源代码控制系统的优势在于它们不必遵循这个模型,但对于新手来说,它似乎更容易掌握.