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

Question

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

概念上更容易使用git init（或其中任何一个）设置DCVS存储库，而不必在SVN的情况下设置外部存储库。

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

Git要求在提交之前明确添加更改的方式与SVN的“提交所有内容”策略相反，在概念上很简单，除非我错了，否则在使用Mercurial时甚至不成问题或者Bazaar。

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

Answer 1

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

• 你有一个中心位置，它始终拥有最先进的官方来源，即SVN服务器
• 由于每个人总是将他的更改与中央服务器合并，因此冲突少得多，手动修复冲突的次数也少得多
• 您可以集中控制来源
• 您有一个正式的修订号而不是修订版哈希，在所有开发人员中都是相同的并且显示正式进度（这是一个向上计数的数字，不像哈希，它只是一个身份指纹，所以你可以看到哪个代码是新的还是更老的，仅仅是这个数字

Answer 2

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

再加上经常缺乏光彩的UI工具（半完成的乌龟实施等），让许多同事为了一个好的UI工具而早已预感命令行的人眼中的一片空白

此外，对于像CVS这样的工具，我发现人们厌恶分支和合并，因为他们真的不想被困一整天进行三向合并，通常不确定哪个是合适的合并。 / p>

我的观点是：首先告诉人们他们获得了什么（不仅仅是“嘿，看看这个新的酷玩具”），并准备他们使用命令行是要走的路，而频繁的恒定时间分支是好事。

许多系统（如mercurial）都带有完整的补丁队列系统，这意味着从持续集成的角度来看，您知道生产的任何内容都已经过质量保证批准。像这样的东西很难用CVS或SVN做好。

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

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

Answer 3

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

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

Answer 4

Svn迫使一条工作线。您可以提交，也可以不提交。有类似的经历，我没有发现Hg或Git难以使用，但是，我在一个似乎发现使用它们的噩梦的团队工作。

自动分支，多头的整个概念，何时以及何时不完全合并都会使他们陷入困境，更不用说他们无法摆脱“使用$ somecore”提交/结账的心态，这会导致完全混淆他们看到两份签出副本之间的推动。

（暂时有问题，有人反复合并了两个不应该合并的分支，因为他们无法理解这个概念。）

但是，那些在分布式SCMS方面遇到问题的人让我问this question

编辑/注意 Mercurials最大的不同之处我注意到vs git让mercurial更难用于新手是mercurial推/拉的默认行为就像做git push --all / git pull - -all，它可以传播私有分支并增加许多混淆（特别是当一个新的分支出现时，mercurial冻结在恐惧中并询问你如何处理它而不仅仅是继续卡车运输），以及默认的合并/冲突Mac上的分辨率工具只是盲目地破坏了一组变化。

Answer 5

我认为SVN的工具集要广泛得多，所以你可以坐下来教人们（TortoiseSVN，RapidSVN等），即使他们对存储库的工作原理没有多少概念。获得为您托管的SVN（例如使用trac）也相对容易，而无需了解任何内容。分布式的那些还没有得到这种支持，我确信他们的意见会在他们这样做时发生变化。

Answer 6

我认为使用DVCS设置存储库几乎更容易，但概念上更难。毕竟，使用集中式VCS，用户不会设置自己的存储库，只需在Assembla上创建一个帐户或为其设置repo。

Answer 7

DVCS目前缺乏优秀的桌面客户端。尽管大多数人都说，版本控制系统很难正确使用，所以一个好的桌面客户端可以提供帮助 - 而TortoiseSVN在这方面表现优异。

Answer 8

我们很难在Codice尽可能地让它变得容易，但是它总是有点难以解释，当然，这取决于观众。

对于OSS项目和小型团队，特别是那些在他们的笔记本电脑上工作并在这里和那里工作，在家工作，有时候在飞机上工作等等的人，这很容易。但是，无论何时与企业/企业交谈，他们都会对其多站点角色感到兴奋，但乍看之下并不是那么多。这完全取决于该集团是否拥有大多数高级开发人员。

Answer 9

这是poor marketing，就这么简单。很多DVCS的介绍都集中在命令行上，并说“哇，不是很棒，你可以通过键入hg merge来进行合并”完全忘记了许多人（特别是在Windows领域）对此感到害怕的事实。命令行。是的，Joel Spolsky，我在这里看着你自己的hginit.com - 我们需要一个TortoiseHg版本！

可能两年前他们的GUI实施效果不佳，但他们最近突然出现了突飞猛进的局面。 TortoiseHg现在是1.0版本，虽然它可能不是什么东西可以在视觉上写回家，但它非常稳固，稳定且易于使用。 TortoiseGit也很坚固，它可以很好地抽象出git命令行的所有复杂性。