集中式和分布式版本控制系统之间的比较[关闭]

哪些优点和缺点使用集中式与分布式版本控制系统（DVCS）？您是否在DVCS中遇到任何问题，并且如何防范这些问题？使讨论工具不可知且不可燃。

对于那些想知道可用的DVCS工具的人，这里列出了最著名的免费/开源DVCS：

• Git（用C编写），由Linux内核和Ruby on Rails使用。
• Mercurial，（用Python编写），由Mozilla和OpenJDK使用。
• Bazaar（用Python编写），由Ubuntu开发人员使用。
• Darcs，（用Haskell编写）。

从我的回答到另一个问题：

分布式版本控制系统（DVCS）与集中式VCS解决了不同的问题。比较它们就像比较锤子和螺丝刀。

集中式VCS系统的设计意图是有一个真实的源头，这是有福的，因此是好源。所有开发人员都从该源工作（签出），然后添加（提交）他们的更改，然后这些更改也同样受到祝福。CVS，Subversion，ClearCase，Perforce，VisualSourceSafe和所有其他CVCS之间的唯一真正区别在于每种产品提供的工作流程，性能和集成。

分布式VCS系统的设计意图是一个存储库与任何其他存储库一样好，并且从一个存储库合并到另一个存储库只是另一种通信形式。关于应该信任哪个存储库的任何语义值都是由过程而不是软件本身从外部施加的。

在使用一种类型或另一种类型之间的真正选择是组织-如果您的项目或组织需要集中控制，那么DVCS就不是首选。如果希望您的开发人员可以在整个国家/世界上工作，而没有到中央存储库的安全宽带连接，那么DVCS可能是您的救星。如果两者都需要，您会感到震惊。

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

话虽如此，我过去一直以为分布式SCM仅对许多做不同事情的开发人员有用，但是最近决定集中式存储库可以做的任何事情都可以做得更好。

例如，假设您是一个从事自己的个人项目的开发人员。集中式存储库可能是一个显而易见的选择，但请考虑这种情况。您没有网络访问权限（在飞机上，公园等），并且想要从事您的项目。您拥有本地副本，因此可以正常工作，但是您确实想提交，因为您已经完成了一项功能并想继续使用另一项功能，或者找到了要修复的错误或其他原因。关键是，使用集中式存储库，您最终要么将所有更改混在一起，然后将其提交到非逻辑更改集中，要么稍后再手动将其拆分。

使用分布式存储库，您可以照常进行事务，提交，继续，当您再次具有网络访问权限时，您将推送到“一个真实的存储库”，而没有任何更改。

更不用说分布式存储库的另一个好处：完整的历史记录始终可用。远离网络时，您需要查看修订日志吗？您需要注释源以查看错误的引入方式？使用分布式存储库，一切皆有可能。

请不要相信分布式与集中式是关于所有权或权威性副本之类的。现实是分布式的，是单片机发展的下一步。

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

集中式VCS

• 颠覆

  Apache，GCC，Ruby，MPlayer，Zope，Plone，Xiph，FreeBSD，WebKit，...

• CVS

  CVS

分布式VCS

• 吉特

  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 ...

• bzr

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

• 达奇

  ghc，ion，xmonad等在Haskell社区中很流行。

• 化石

  SQLite的

W. Craig Trader谈到了DVCS和CVCS：

如果两者都需要，您会感到震惊。

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

与CVCS相比，DVCS有一些优点：

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

• 您可以拥有不需要展示给其他人的本地实验分支（克隆的存储库也可以被视为分支）。这意味着，如果您没有向上游推销任何东西，那么打破变更就不会影响开发人员。在CVCS中，当您仍有重大更改时，您可能必须脱机工作，直到您对其进行修复并在那时提交更改为止。这种方法有效地克服了使用版本控制作为安全网的目的，但这在CVCS中是必不可少的。

• 在当今世界，公司通常与离岸开发人员合作（或者，如果更好，他们希望在家工作）。拥有DVCS可以帮助进行此类项目，因为每个人都有自己的存储库，因此无需可靠的网络连接。

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

• 谁拥有最新版本？在CVCS中，中继线通常具有最新版本，但是在DVCS中，它可能不是很明显。解决方法是使用行为规则，即项目中的开发人员必须达成协议，在该协议中回购才能合并其工作。

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

• 在专有项目中，如果整个存储库都可以公开使用，那将是灾难性的。如果不满或恶意的程序员掌握了克隆的存储库，则更是如此。源代码泄漏是专有企业的严重痛苦。DVCS使这一点变得很简单，因为您只需要克隆存储库，而某些CM系统（例如ClearCase）则试图限制该访问。但是，我认为，如果您在公司文化中有足够多的功能失调，那么世界上没有任何版本控制可以帮助您防止源代码泄漏。

在寻找合适的SCM期间，我发现以下链接有很大帮助：

1. 更好的SCM倡议：比较。比较约26个版本控制系统。
2. 版本控制软件比较。Wikipedia文章比较了大约38个版本控制系统，涵盖了技术差异，功能，用户界面等主题。
3. 分布式版本控制系统。另一个比较，但主要集中在分布式系统上。

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

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

话虽这么说，DVCS传统上做得很好，但大多数集中式VCS却有些杂乱无章。其中最重要的可能是分支：DVCS将使分支存储库或合并不再需要的分支变得非常容易，并且在执行过程中将保持历史记录。集中式方案对此没有任何特殊原因，但历史上似乎没有人完全正确。对于您而言，这实际上是否是一个问题取决于您如何组织开发，但是对于许多人来说，这是一个重要的考虑因素。

DVCS的另一个优点是它们可以脱机工作。我从来没有真正用过很多。我主要在办公室（因此存储库在本地网络上）或在家（因此有ADSL）进行开发。如果您在旅途中使用笔记本电脑进行了大量开发工作，那么这可能更适合您。

实际上，没有很多特定于DVCS的陷阱。人们安静的趋势要大一些，因为您可以不费吹灰之力就做出承诺，很容易最终私下里弄点东西，但是除此之外，我们没有太多问题。这可能是因为我们有大量的开源开发人员，他们通常熟悉开发的补丁程序交易模型，但是新进来的封闭源代码开发人员似乎也能很快地进行开发。

我使用Subversion已经很多年了，对此我感到非常满意。

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

任何dvc都可以使用中央服务器进行设置，但是除了其他功能外

您可以签入自己喜欢的任何小更改，如Linus所说，如果您需要使用一个以上的句子来描述您刚刚所做的事情，那么您做得太多了。您可以在本地进行代码，分支，合并，克隆和测试，而不会导致任何人下载大量数据。您只需要将最终更改推送到中央服务器即可。

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

简而言之，使用版本控制始终是一件好事。使用dvc便宜（以KB和带宽为单位），我认为使用起来更有趣。

结帐Git：http : //git-scm.com/
结帐化石：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如何出类拔萃，但是Craig的评论很重要。在DVCS中，每个人都有分支的整个历史记录。如果您要处理大量二进制文件（例如，图像文件或FLA），则需要大量空间，因此无法进行比较。

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

即使在单独的开发人员场景中，分布式SCM的另一个优点是，如果您像我们中的许多人一样拥有一台以上的计算机在工作。

假设您有一组通用脚本。如果您使用的每台计算机都有一个克隆，则可以按需更新和更改脚本。它为您提供：

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

W. Craig Trader的答案可以概括其中的大部分内容，但是，我发现个人工作风格也有很大的不同。在我目前工作的地方，我们使用subversion作为我们的“真实来源”，但是，许多开发人员在其个人计算机上使用git-svn来弥补我们遇到的工作流问题（管理失败，但这是另一回事了）。任何状况之下。它实际上是在平衡哪些功能集使您最有效地满足组织的需求（例如集中式身份验证）方面。

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

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