集中式与分布式版本控制系统的比较

使用 集中式与分布式版本控制系统(DVCS)的 利与弊是什么？您在 DVCS 中遇到过任何问题吗? 您是如何防止这些问题的？保持讨论工具的不可知性和火焰最小化。

对于那些想知道有哪些 DVCS 工具可用的人来说，下面列出了最著名的免费/开源 DVCS:

66396 次浏览
小开

主要问题(除了明显的带宽问题)是 所有权。

这是为了确保不同的(地理)站点不工作在相同的元素比其他。

理想情况下，该工具能够将所有权分配给文件、分支甚至存储库。

要回答这个问题，你真的需要这个工具来告诉你谁拥有什么，并且 那么(通过电话、即时通讯或邮件)与远程站点通信。
如果您没有所有权机制... ... 您将“通信”，但往往为时已晚;)(即: 在同一分支中的相同文件集上完成并发开发之后。提交可能会变得混乱)

小开

对我来说，这是另一个关于个人品味的讨论，很难真正客观。相对于其他 DVCS，我个人更喜欢 反复无常。我喜欢用与 反复无常编写语言相同的语言编写钩子，而且网络开销较小——这只是我个人的一些原因。

小开

我有一种感觉，Mercurial (和其他 DVCS)比集中式的更复杂。例如，在 Mercurial 中合并一个分支将保留该分支的完整历史记录，而在 SVN 中，您必须转到分支目录才能查看历史记录。

小开
最佳答案

从 我的回答到另一个 有个问题:

分布式版本控制系统 (DVCS)解决不同的问题 集中式 VCS。比较它们是 比较锤子和 螺丝刀。

集中式 VCS 系统是 设计的意图是 一个被祝福的真正源头 因此，很好。所有的开发人员工作 (结帐)从那个来源，然后 添加(提交)他们的更改，然后 成为同样的受祝福的。唯一的 CVS 之间的真正区别, Subversion ClearCase Perforce, VisualSourceSafe 等等 CVCSes 在工作流中, 性能，以及整合，每个 产品优惠。

分布式 VCS 系统是 设计的意图是 储存库和其他储存库一样好, 从一个仓库合并到 另一种只是另一种形式的 交流。任何语义价值作为 应该信任哪个存储库 是由外界强加的 过程，而不是由软件本身。

在使用一种类型之间的真正选择 或者是有组织的——如果 你的项目或组织需要 集中控制，则 DVCS 是一个 如果你的开发商 希望在全国范围内工作 没有安全保障的国家/世界 与中心的宽带连接 存储库，那么 DVCS 可能是您的 救赎，如果你两者都需要 完蛋了。

小开

然而，我发现个人的工作风格也有很大的不同。在我目前工作的地方，我们使用 subversion 作为我们的 One True Source，然而，许多开发人员在他们的个人机器上使用 git-svn 来弥补我们遇到的工作流问题(管理失败，但那是另一回事)。无论如何。它实际上是关于平衡哪些特性集使您的工作效率最高，以及组织需要什么(例如，集中式身份验证)。

小开

在我寻找正确的供应链管理的过程中，我发现以下链接非常有帮助:

  1. 更好的 SCM 主动性: 比较大约26个版本控制系统的比较。
  2. 修订控制软件比较。Wikipedia 文章比较了38个版本控制系统，包括技术差异、特性、用户界面等等。
  3. 分布式版本控制系统。另一个比较，但主要集中在分布式系统。
小开

对于那些认为分布式系统不允许权威的人来说 请注意，有很多地方分发 系统有权威的副本，完美的例子可能是 李纳斯的内核树。当然很多人都有自己的树，但是 几乎都流向了莱纳斯的树。

也就是说，我过去常常认为分布式 SCM 只有在以下情况下才有用 许多开发人员做不同的事情，但最近已经决定 集中存储库可以做的任何事情，分布式存储库都可以做 好多了。

例如，假设你是一个独立开发人员，正在开发自己的个人产品 一个集中的存储库可能是一个明显的选择，但 考虑这个场景。你远离网络访问(在飞机上, 在公园等地) ，并希望为你的项目工作。你有你的本地 复制，所以你可以做的很好，但你真的想承诺，因为你 已经完成了一个特性并且想要转移到另一个特性，或者你发现 一个需要修复的错误或者其他什么的。关键是通过一个集中的回购 最终要么将所有更改混合在一起并提交它们 或者稍后手动将它们分开。

在分布式回购中，你像往常一样做生意，承诺，继续前进, 当你有网络访问再次你推到你的“一个真正的回购”和 什么都没变。

更不用说分布式回购的另一个好处: 完整 历史记录始终可用。需要在下列情况下查看修订日志 远离网络? 你需要注释的来源，看看如何一个错误 介绍? 所有可能的分布式回购协议。

请不要相信分布式与集中式 所有权或权威的副本或类似的东西。现实 分布式是供应链管理发展的下一步。

小开

克雷格交易员(W. Craig Trader)对 DVCS 和 CVCS 说:

如果你两样都需要，你就死定了。

我不会说你是 去死吧当使用两者。实际上，使用 DVCS 工具的开发人员通常会尝试将他们的更改(或发送请求)合并到一个中心位置(通常是发布存储库中的发布分支)。对于使用 DVCS 的开发人员来说有些讽刺，但最终还是坚持使用集中式工作流，您可能会开始怀疑分布式方法是否真的比集中式方法更好。

与 CVCS 相比，DVCS 有一些优势:

  • 唯一可识别提交的概念使得在对等点之间发送补丁变得无痛。也就是说，你把补丁作为一个提交，并与其他需要它的开发人员共享。稍后，当每个人都希望合并在一起时，将识别特定的提交，并且可以在分支之间进行比较，从而减少发生合并冲突的机会。不管您使用的版本控制工具是什么，开发人员都倾向于通过 USB 棒或电子邮件相互发送补丁。不幸的是，在 CVCS 情况下，版本控制会将提交注册为单独的，未能认识到更改是相同的，从而导致更高的合并冲突机会。

  • 您可以拥有不需要向其他人显示的本地实验分支(克隆存储库也可以被视为一个分支)。这意味着，如果您没有将任何东西推向上游，那么破坏性更改不一定会影响到开发人员。在 CVCS 中，如果仍然存在重大更改，则可能必须脱机工作，直到修复了更改并在此之前提交更改。这种方法有效地破坏了使用版本控制作为安全网的目的，但是在 CVCS 中它是一个必要的缺点。

  • 在当今世界，公司通常与离岸开发人员合作(如果更好的话，他们希望在家工作)。有一个 DVCS 可以帮助这些项目，因为它消除了可靠的网络连接的需要，因为每个人都有自己的回购。

... 和一些通常有变通方法的缺点:

  • 谁有最新的修订版？在 CVCS 中，主干通常有最新的版本，但在 DVCS 中，它可能并不明显。解决办法是使用行为准则，即项目中的开发人员必须达成一项协议，在这项协议中回购合并他们的工作。

  • 悲观锁定，即文件在签出时被锁定，通常是不可能的，因为在 DVCS 中存储库之间可能发生并发。版本控制中存在文件锁定的原因是开发人员希望避免合并冲突。然而，锁定的缺点是会减慢开发速度，因为两个开发人员不能像处理长事务模型那样同时处理同一段代码，而且对于合并冲突也没有完全的保证。无论版本控制如何，唯一明智的方法是解决大的合并冲突，就是拥有良好的代码体系结构(比如低耦合高内聚) ，并划分您的工作任务，以便它们对代码的影响较小(这说起来容易做起来难)。

  • 在专有项目中，如果整个存储库变得公开可用，那将是灾难性的。如果心怀不满或怀有恶意的程序员获得了克隆的存储库，情况更是如此。源代码泄露对于专有企业来说是一个严重的问题。DVCS 简化了这一过程，因为您只需要克隆存储库，而一些 CM 系统(比如 ClearCase)试图限制这种访问。然而，在我看来，如果您的公司文化中有足够多的功能失调，那么世界上没有任何版本控制可以帮助您防止源代码泄漏。

小开

集中式系统并不一定阻止您使用单独的分支进行开发。不需要代码库的单个真实副本，相反，不同的开发人员或团队可以有不同的分支，遗留分支可以存在等等。

这通常意味着存储库是集中管理的——但对于一个拥有称职 IT 部门的公司来说，这通常是一个优势，因为它意味着只有一个地方可以备份，只有一个地方可以管理存储。

小开

在某种程度上，这两个方案是等同的:

  • 如果您总是在每次本地提交之后将更改推送到某个指定的上游存储库，那么分布式 VCS 可以很容易地模拟集中式 VCS。
  • 集中式 VCS 通常不能很自然地模拟分布式 VCS，但是如果在它上面使用类似于 被子的东西，就可以得到非常类似的东西。Quilt，如果你不熟悉它，它是一个在上游项目上管理大型补丁集的工具。这里的想法是，DVCS 提交命令是通过创建一个新的补丁来实现的，push 命令是通过将每个未完成的补丁提交给集中的 VCS，然后丢弃补丁文件来实现的。这听起来有点尴尬，但在实践中，它实际上工作得相当不错。

话虽如此，有几件事情 DVCSes 传统上做得很好，而大多数集中的 VCSes 做得有点杂乱无章。其中最重要的可能是分支: DVCS 将使对存储库进行分支或合并不再需要的分支变得非常容易，并且在您这样做时将跟踪历史记录。没有什么特别的原因可以解释为什么一个集中的计划会遇到这样的麻烦，但是从历史上来看，似乎还没有人能够完全正确地解决这个问题。这对你来说是否真的是个问题，取决于你如何组织开发，但对许多人来说，这是一个重要的考虑因素。

DVCSes 的另一个优势是它们可以离线工作。我从来没有真正使用过它; 我主要在办公室(所以存储库在本地网络上)或家里(所以有 ADSL)进行开发。如果你在旅行的时候在笔记本电脑上做了很多开发工作，那么这可能是你更需要考虑的。

实际上并没有很多陷阱是特定于 DVCSes 的。人们更倾向于保持沉默，因为你可以不强迫自己做出承诺，而且很容易在私下里擦亮东西，但除此之外，我们没有遇到很多问题。这可能是因为我们有相当数量的开源开发人员，他们通常熟悉开发的补丁交易模型，但是即将到来的封闭源代码开发人员似乎也能相当快地学会这些东西。

小开

这并不是一个比较，但是下面是一些大型项目正在使用的方法:

中央视觉系统

  • 颠覆

    Apache，gCC，Ruby，mPlayer，Zope，Plone，Xiph，FreebSD，WebKit，...

  • CVS

分布式 VCSes

  • Linux 内核，KDE，Perl，Ruby on Rails，Android，Wine，Fedora，X.org，Mediawiki，Django，vLC，Mono，Gnome，Samba，CUPS，gnuPG，Emacs ELPA..。

  • 汞(汞)

    Mozilla 和 Mozdev，OpenJDK (Java) ，OpenSolaris，ALSA，NTFS-3G，Dovecot，MoinMoin，mutt，PETSc，Octave，FEniCS，Aptitude，Python，XEmacs，Xen，Vim，Xine..。

  • Emacs，Apt，Mailman，MySQL，Squid，... 也在 Ubuntu 中得到了提升。

  • Darcs

    Ghc，ion，xmonad，... 在哈斯克尔社区很受欢迎。

  • 化石

    SQLite

小开

我已经使用颠覆很多年了，我真的很高兴。

然后 GIT 的嗡嗡声开始了，我只需要测试一下。对我来说，主要的卖点是分支。哦，天啊。现在，我不再需要清理我的存储库，回到一些版本或任何愚蠢的事情，我使用 subversion 时。在 dvc 里所有东西都很便宜。虽然我只试过化石和 git，但我使用了 perforce、 cvs 和 subversion，看起来 dvcs 都有非常便宜的分支和标签。不再需要将所有代码复制到一边，因此合并只是一件轻而易举的事情。

任何 dvcs 都可以通过中央服务器进行设置，但您所获得的是其他功能之一

你可以检查任何你喜欢的小改变，正如莱纳斯所说，如果你需要用一个以上的句子来描述你刚刚做了什么，你做得太多了。 你可以按照自己的方式处理代码、分支、合并、克隆和测试，而不会导致任何人下载大量数据。 您只需要将最后的更改推送到中央服务器。

你可以在没有网络的情况下工作。

所以简而言之，使用版本控制总是一件好事。使用 dvcs 更便宜(KB 和带宽) ，而且我认为使用它更有趣。

结帐 Git: http://git-scm.com/
返回文章页面检验化石 http://www.Fossil-scm.org :
结帐 Mercurial: https://www.mercurial-scm.org

现在，我只能推荐 dvcs 系统，您可以很容易地使用中央服务器

小开

分布式 SCM 的另一个好处是，即使在独立开发人员的场景中，如果您像我们中的许多人一样，使用多台机器工作。

假设您有一组通用脚本。如果您使用的每台机器都有一个克隆，那么您可以根据需要更新和更改您的脚本。它给你:

  1. 节省时间，尤其是使用 ssh 键
  2. 一种分支不同系统之间差异的方法(例如 Red Hat vs Debian，BSD 与 Linux 等)
小开

分布式 VCS 在许多方面都很有吸引力，但对我的公司来说，一个重要的缺点是管理不可合并文件(通常是二进制文件，例如 Excel 文档)的问题。Subversion 通过支持“ svn: need-lock”属性来处理这个问题，这意味着在编辑不可合并文件之前必须为它获得一个锁。效果很好。但是这种工作流需要一个集中的存储库模型，这与 DVCS 的概念相反。

因此，如果您想使用 DVCS，那么它实际上不适合管理不可合并的文件。

小开

现在每个人都在追捧 DVCS 的优越性，但克雷格的评论很重要。在 DVCS 中，每个人都有该分支的全部历史。如果您使用大量的二进制文件(例如，图像文件或 FLA) ，这需要大量的空间，您不能做差异。


提交答案