version-control - 集中式和分布式版本控制系统的比较

使用集中式与分布式版本控制系统（DVCS）的优点和缺点是什么？您是否遇到过DVCS的任何问题？您是如何防范这些问题的？ 保持讨论工具不可知和火焰最小化。

对于那些想知道什么是DVCS工具的人，这里有一个最着名的免费/开源DVCS列表：

Mercurial，（用Python编写）Mozilla and OpenJDK使用。
Bazaar，（用Python编写）Ubuntu developers使用。
Darcs，（用Haskell编写）。

分布式版本控制系统   （DVCSs）解决不同的问题   集中式VCS。比较它们是   比如锤子和锤子   螺丝起子。

Centralized VCS系统是   设计的目的是有   一个有福的真正来源，和   好，好。所有开发者都工作   （结账）来自该来源，然后   添加（提交）他们的更改，然后   变得同样有福了。唯一的   CVS之间真正的区别，   Subversion，ClearCase，Perforce，   VisualSourceSafe和所有其他   CVCSes在工作流程中，   每个人的表现和整合   产品报价。

Distributed VCS系统是   旨在设计一个   存储库和其他存储库一样好，   并且从一个存储库合并到   另一种只是另一种形式   通讯。任何语义值为   应该信任哪个存储库   是从外面施加的   过程，而不是软件本身。

使用一种类型之间的真正选择   或者另一个是组织 - 如果   您的项目或组织想要的   集中控制，然后DVCS是一个   非首发。如果您的开发人员是   预计将全职工作   国家/世界，没有安全   宽带连接到中央   存储库，然后DVCS可能是你的   救恩。如果你需要两者，你就是   fsck'd。

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

那就是说我认为分布式SCM只对它有用   许多开发人员做了不同的事情，但最近已经决定   任何集中式存储库都可以做分布式存储库   更好。

例如，假设您是一名独立开发人员   项目。集中式存储库可能是一个明显的选择，但是   考虑这种情况。你远离网络访问（在飞机上，   在公园等，并希望在您的项目上工作。你有当地人   复制，这样你就可以做得很好，但你真的想要提交，因为你   完成了一个功能，想要转移到另一个功能，或者你找到了   要修复的错误或其他什么。重点是集中回购   你最终将所有的变化混合在一起并提交它们   在非逻辑变更集中，或者您稍后手动拆分它们。

通过分布式回购，您可以照常营业，继续前进，   当你再次拥有网络访问权限时，你会推送到“真正的回购”   没有改变。

更不用说分布式回购的另一个好处：完整   始终有历史。您需要查看修订日志   远离网？您需要注释源代码以查看错误   被介绍了吗？所有可能的分布式回购。

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

不是真正的比较，但以下是大型项目正在使用的内容：

集中式VCS

<强> Subversion

Apache，GCC，Ruby，MPlayer，Zope，Plone，Xiph，FreeBSD，WebKit，......
<强> CVS

CVS

分布式VCS

<强> git

Linux内核，KDE，Perl，Ruby on Rails，Android，Wine，Fedora，X.org，Mediawiki，Django，VLC，Mono，Gnome，Samba，CUPS，GnuPG，Emacs ELPA ......
< / LI>
<强> mercurial (hg)

Mozilla和Mozdev，OpenJDK（Java），OpenSolaris，ALSA，NTFS-3G，Dovecot，MoinMoin，mutt，PETSc，Octave，FEniCS，Aptitude，Python，XEmacs，Xen，Vim，Xine ......
<强> bzr

Emacs，Apt，Mailman，MySQL，Squid，...也在Ubuntu内推广。
<强> darcs

ghc，ion，xmonad，...在Haskell社区中很受欢迎。
<强> fossil

SQLite的

W. Craig Trader说到DVCS和CVCS：

如果你需要两者，你就是fsck'd。

使用两者时，我不会说你是 fsck'd 。实际上，使用DVCS工具的开发人员通常会尝试将其更改（或发送拉取请求）合并到中央位置（通常是发布存储库中的发布分支）。对于使用DVCS但最终坚持使用集中式工作流程的开发人员来说，有一些讽刺意味，你可以开始怀疑分布式方法是否真的比集中式更好。

DVCS相对于CVCS有一些优势：

唯一可识别提交的概念使得在对等点之间发送补丁变得无痛。即您将补丁作为提交，并与需要它的其他开发人员共享。稍后当每个人都希望合并在一起时，该特定提交被识别并且可以在分支之间进行比较，具有较少的合并冲突机会。无论您使用何种版本工具，开发人员都倾向于通过USB记忆棒或电子邮件相互发送补丁。不幸的是，在CVCS的情况下，版本控制会将提交注册为单独的，未能识别出更改是相同的，从而导致合并冲突的可能性更高。
您可以将本地实验分支（克隆的存储库也可以视为分支），您不需要向其他人展示。这意味着，如果您没有向上游推送任何内容，那么破坏更改不需要影响开发人员。在CVCS中，当您仍然有一个重大变化时，您可能必须脱机工作，直到您修复它并提交更改为止。这种方法有效地破坏了使用版本控制作为安全网的目的，但它在CVCS中是一个必要的恶魔。
在当今世界，公司通常与离岸开发商合作（或者如果他们想在家工作更好）。拥有DVCS有助于推出这类项目，因为它消除了对可靠网络连接的需求，因为每个人都有自己的回购。

......以及通常有解决方法的一些缺点：

谁拥有最新版本？在CVCS中，主干通常具有最新版本，但在DVCS中，它可能并不明显。解决方法是使用行为规则，项目中的开发人员必须达成协议，将repo合并到其中。
悲观锁定，即文件在签出时被锁定，通常是不可能的，因为DVCS中的存储库之间可能发生并发。版本控制中存在文件锁定的原因是因为开发人员希望避免合并冲突。但是，锁定具有减慢开发速度的缺点，因为两个开发人员不能像长事务模型那样同时处理同一段代码，并且它不能完全抵御合并冲突。无论版本控制如何，唯一合理的方法是解决大的合并冲突，就是要有良好的代码架构（比如低耦合高内聚）并分割你的工作任务，这样它们对代码的影响很小（这说起来容易做起来难）
在专有项目中，如果整个存储库公开可用，那将是灾难性的。如果心怀不满或恶意的程序员获得克隆的存储库，情况更是如此。源代码泄漏对于专有企业来说是一个严重的痛苦。 DVCS使得这很简单，因为您只需要克隆存储库，而某些CM系统（例如ClearCase）会尝试限制该访问。但是在我看来，如果你的公司文化中有足够的功能失调，那么世界上没有任何版本控制可以帮助你防止源代码泄漏。

在我搜索合适的SCM期间，我发现以下链接非常有用：

Better SCM Initiative : Comparison。大约26个版本控制系统的比较。
Comparison of revision control software。维基百科文章比较了38个版本控制系统，涵盖技术差异，功能，用户界面等主题。
Distributed version control systems。另一个比较，但主要集中在分布式系统上。

在某种程度上，这两种方案是等价的：

如果您在每次本地提交后始终将更改推送到某个指定的上游存储库，则分布式VCS可以轻松模拟集中式VCS。
集中式VCS通常不能自然地模拟分布式VCS，但如果在其上使用quilt之类的东西，则可以获得非常相似的东西。如果你不熟悉被子，它是一个在一些上游项目之上管理大量补丁的工具。这里的想法是通过创建新补丁来实现DVCS commit命令，并且通过将每个未完成的补丁提交到集中式VCS然后丢弃补丁文件来实现push命令。这听起来有点尴尬，但在实践中它确实很有效。

话虽如此，DVCS传统上做得很好，而且大多数集中式VCS都有一些哈希值。其中最重要的可能是分支：DVCS将使分支存储库或合并不再需要的分支变得非常容易，并且会在您执行此操作时跟踪历史记录。没有特别的理由为什么集中式计划会遇到这个问题，但从历史上看，似乎没有人能够做到这一点。这对你来说实际上是一个问题取决于你将如何组织开发，但对于很多人来说这是一个重要的考虑因素。

DVCSes的另一个优势是它们可以离线工作。我从来没有真正用过那么多;我主要是在办公室（所以在本地网络上的存储库）或在家里（所以有ADSL）进行开发。如果您在旅行时对笔记本电脑进行了大量的开发，那么这可能是您的一个考虑因素。

实际上并没有很多特定于DVCS的陷阱。人们有一种稍微倾向于保持安静的倾向，因为你可以在不推动的情况下进行投入，并且很容易在私下抛光，但除此之外我们没有遇到很多问题。这可能是因为我们有大量的开源开发人员，他们通常熟悉开发的补丁交易模型，但是传入的封闭源代码开发人员似乎也能快速合理地开发。

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

然后GIT的嗡嗡声响起，我只需要测试它。对我来说，主要卖点是分支。好家伙。现在我不再需要清理我的存储库，返回一些版本或使用subversion时所做的任何愚蠢的事情。在dvcs中一切都很便宜。我只尝试过化石和git，但是我使用了perforce，cvs和subversion，看起来dvcs都有非常便宜的分支和标记。不再需要将所有代码复制到一边，因此合并只是轻而易举。

任何dvcs都可以使用中央服务器进行设置，但您获得的是

你可以检查你喜欢的任何小改变，正如Linus所说，如果你需要用一个以上的句子来描述你刚刚做了什么，你做得太多了。您可以使用代码，分支，合并，克隆和测试所有本地，而不会导致任何人下载大量数据。而且您只需要将最终更改推送到中央服务器。

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

简而言之，使用版本控制总是一件好事。使用dvcs更便宜（以KB和带宽为单位），我认为使用它会更有趣。

结账Git：http://git-scm.com/
结帐Fossil：http://www.fossil-scm.org
要结帐Mercurial：https://www.mercurial-scm.org

现在，我只能推荐dvcs系统，您可以轻松使用中央服务器

分布式VCS在很多方面具有吸引力，但对我公司来说一个重要的缺点是管理不可合并的文件（通常是二进制文件，例如Excel文档）。 Subversion通过支持“svn：needs-lock”属性来处理这个问题，这意味着在编辑之前必须锁定非可合并文件。它运作良好。但是，该工作流程需要一个集中的存储库模型，这与DVCS概念相反。

因此，如果您想使用DVCS，则不适合管理不可合并的文件。

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

这是为了确保不同（地理）的网站不在同一个元素上工作。

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

要回答此答案的评论，您真的希望该工具告诉您谁拥有什么，然后然后与远程站点进行通信（通过电话，IM或邮件）。
如果你没有所有权机制......你将“沟通”，但往往为时已晚;）（即：在同一分支中对同一组文件进行并发开发之后。提交可能会变得混乱）

对我而言，这是另一个关于个人品味的讨论，而且很难真正客观。我个人更喜欢Mercurial而不是其他DVCS。我喜欢使用与编写Mercurial相同的语言编写钩子，并且网络开销较小 - 仅仅是出于我自己的原因。

现在，每个人都在谈论DVCS如何优越，但克雷格的评论非常重要。在DVCS中，每个人都拥有分支的整个历史。如果你正在使用大量的二进制文件（例如，图像文件或FLA），这需要大量的空间，你不能做差异。

我觉得Mercurial（和其他DVCS）比集中式更复杂。例如，在Mercurial中合并分支会保留分支的完整历史记录，而在SVN中，您必须转到分支目录才能查看历史记录。

即使在单独的开发人员场景中，分布式SCM的另一个好处是，如果您和我们中的许多人一样，您可以使用多台计算机。

假设您有一组常用脚本。如果您使用的每台计算机都有一个克隆，您可以按需更新并更改脚本。它给你：

节省时间，特别是使用ssh键
一种分支不同系统之间差异的方法（例如Red Hat vs Debian，BSD vs Linux等）

W上。 Craig Trader的答案总结了大部分内容，然而，我发现个人工作风格也有很大差异。在我目前工作的地方，我们使用subversion作为我们的One True Source，然而，许多开发人员在他们的个人机器上使用git-svn来弥补我们的工作流程问题（管理失败，但这是另一个故事）。在任何情况下。它真正关于平衡哪些功能集使您最有效率与组织需要（例如集中身份验证）。

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

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

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

15 个答案:

集中式VCS

分布式VCS