使用集中式与分布式版本控制系统 (DVCS)的优缺点是什么？您在 DVCS 中遇到过任何问题吗？您是如何防范这些问题的？保持讨论工具不可知论和燃烧到最低限度。
对于那些想知道有哪些 DVCS 工具可用的人，这里是最知名的免费/开源 DVCS 列表：
分布式版本控制系统 (DVCS) 解决了与集中式 VCS 不同的问题。比较它们就像比较锤子和螺丝刀。
集中式 VCS系统的设计意图是存在一个受祝福的真正来源，因此是好的。所有开发人员都从该源工作（签出），然后添加（提交）他们的更改，然后这些更改变得类似 Blessed。CVS、Subversion、ClearCase、Perforce、VisualSourceSafe 和所有其他 CVCS 之间唯一真正的区别在于每个产品提供的工作流程、性能和集成。
分布式 VCS系统的设计意图是一个存储库与其他存储库一样好，并且从一个存储库合并到另一个存储库只是另一种通信形式。关于应该信任哪个存储库的任何语义值都是由进程从外部强加的，而不是由软件本身强加的。
使用一种类型或另一种类型的真正选择是组织性的——如果您的项目或组织想要集中控制，那么 DVCS 是不可能的。如果您的开发人员需要在全国/世界各地工作，而没有与中央存储库的安全宽带连接，那么 DVCS 可能是您的救星。如果你两者都需要，那你就完蛋了。
对于那些认为分布式系统不允许权威副本的人，请注意分布式系统有很多地方都有权威副本，最好的例子可能是 Linus 的内核树。当然很多人都有自己的树，但几乎所有人都流向了莱纳斯的树。
也就是说，我曾经认为分布式 SCM 只对许多开发人员做不同的事情有用，但最近决定集中存储库可以做的任何事情，分布式存储库可以做得更好。
例如，假设您是一名独立开发人员，致力于您自己的个人项目。集中式存储库可能是一个明显的选择，但请考虑这种情况。您远离网络访问（在飞机上、在公园等）并且想要处理您的项目。你有你的本地副本，所以你可以很好地工作，但你真的想提交，因为你已经完成了一个功能并想继续另一个功能，或者你发现了一个要修复的错误或其他什么。关键是，使用集中式存储库，您最终要么将所有更改混合在一起并将它们提交到非逻辑更改集中，要么稍后手动将它们拆分出来。
使用分布式存储库，您可以照常营业，提交，继续前进，当您再次拥有网络访问权限时，您将推送到“一个真正的存储库”并且没有任何改变。
更不用说分布式存储库的另一个好处：始终可用的完整历史记录。离网时需要查看修订日志吗？您需要对源代码进行注释以查看错误是如何引入的？分布式回购一切皆有可能。
请不要相信分布式与集中式是关于所有权或权威副本或类似的东西。现实是分布式的，是 SCM 演进的下一步。
不是真正的比较，但这里是大型项目正在使用的：
Apache, GCC, Ruby, MPlayer, Zope, Plone, Xiph, FreeBSD, WebKit, ...
CVS
CVS
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 中得到推广。
ghc, ion, xmonad, ... 在 Haskell 社区中很流行。
SQLite
W. Craig Trader谈到了 DVCS 和 CVCS：
如果你两者都需要，那你就完蛋了。
我不会说你在使用两者时都会被淘汰。实际上，使用 DVCS 工具的开发人员通常会尝试将他们的更改（或发送拉取请求）合并到一个中心位置（通常是发布存储库中的发布分支）。对于使用 DVCS 但最终坚持使用集中式工作流程的开发人员来说，有些讽刺意味，您可能会开始怀疑分布式方法是否真的比集中式更好。
与 CVCS 相比，DVCS 有一些优势：
唯一可识别的提交的概念使得在对等点之间发送补丁变得轻松。即，您将补丁作为提交，并与其他需要它的开发人员共享。稍后当每个人都想合并在一起时，该特定提交会被识别并可以在分支之间进行比较，从而减少合并冲突的机会。无论您使用哪种版本控制工具，开发人员都倾向于通过 U 盘或电子邮件相互发送补丁。不幸的是，在 CVCS 案例中，版本控制会将提交注册为单独的，无法识别更改是相同的，从而导致合并冲突的可能性更高。
您可以拥有不需要向其他人展示的本地实验分支（克隆的存储库也可以被视为一个分支）。这意味着，如果您没有向上游推送任何内容，那么重大更改不需要影响开发人员。在 CVCS 中，当您仍然有重大更改时，您可能必须离线工作，直到您修复它并提交更改。这种方法有效地破坏了使用版本控制作为安全网的目的，但它在 CVCS 中是一个必要的弊端。
在当今世界，公司通常与离岸开发人员合作（或者甚至更好，他们希望在家工作）。拥有 DVCS 有助于此类项目，因为它消除了对可靠网络连接的需求，因为每个人都有自己的存储库。
…以及通常有解决方法的一些缺点：
谁有最新版本？在 CVCS 中，主干通常具有最新版本，但在 DVCS 中可能并不明显。解决方法是使用行为规则，项目中的开发人员必须达成一项协议，在该协议中合并他们的工作。
悲观锁，即在签出时锁定文件，通常是不可能的，因为 DVCS 中的存储库之间可能发生并发。版本控制中存在文件锁定的原因是开发人员希望避免合并冲突。但是，锁定的缺点是会减慢开发速度，因为两个开发人员不能像使用长事务模型那样同时处理同一段代码，并且它不能完全证明对合并冲突的保证。无论版本控制如何，唯一明智的方法是对抗大型合并冲突是拥有良好的代码架构（如低耦合高内聚）并划分您的工作任务，以便它们对代码的影响较小（说起来容易做起来难） .
在专有项目中，如果整个存储库都公开可用，那将是灾难性的。如果心怀不满或恶意的程序员掌握了克隆的存储库，则更是如此。源代码泄露是专有业务的一大痛点。DVCS 使这变得简单，因为您只需要克隆存储库，而一些 CM 系统（例如 ClearCase）试图限制该访问。但是，在我看来，如果您的公司文化中有足够多的功能失调，那么世界上没有任何版本控制可以帮助您防止源代码泄漏。
在寻找合适的 SCM 时，我发现以下链接很有帮助：
在某种程度上，这两种方案是等价的：
话虽如此，有几件事是 DVCS 传统上做得很好，而大多数集中式 VCS 做了一些散列。其中最重要的可能是分支：DVCS 将使存储库的分支或合并不再需要的分支变得非常容易，并且在您这样做时会跟踪历史记录。没有什么特别的原因会导致集中式方案在这方面遇到麻烦，但从历史上看，似乎还没有人完全正确地做到这一点。这对您来说是否真的是一个问题取决于您将如何组织开发，但对于许多人来说，这是一个重要的考虑因素。
DVCS 的另一个假定优势是它们可以离线工作。我从来没有真正用过它。我主要在办公室（所以存储库在本地网络上）或在家（所以有 ADSL）进行开发。如果您在旅行时在笔记本电脑上进行大量开发，那么这可能更适合您考虑。
实际上并没有很多专门针对 DVCS 的陷阱。人们更倾向于保持安静，因为你可以在没有推动的情况下做出承诺，而且很容易私下里打磨事情，但除此之外，我们并没有遇到太多问题。这可能是因为我们有大量的开源开发人员，他们通常熟悉补丁交易开发模型，但新来的闭源开发人员似乎也能相当快地掌握这些东西。
我已经使用 subversion 很多年了，我对它真的很满意。
然后 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 的优越性，但 Craig 的评论很重要。在 DVCS 中，每个人都有分支的全部历史。如果您正在处理大量二进制文件（例如，图像文件或 FLA），则这需要大量空间并且您无法进行差异。
我感觉 Mercurial（和其他 DVCS）比集中式的更复杂。例如，在 Mercurial 中合并分支会保留分支的完整历史记录，而在 SVN 中，您必须转到分支目录才能查看历史记录。
即使在单独的开发人员场景中，分布式 SCM 的另一个优点是，如果您像我们中的许多人一样，拥有不止一台工作的机器。
假设您有一组通用脚本。如果您使用的每台机器都有一个克隆，您可以按需更新和更改您的脚本。它为您提供：
W. Craig Trader 的回答总结了大部分内容，但是，我发现个人工作风格也有很大的不同。在我目前工作的地方，我们使用 subversion 作为我们的 One True Source，然而，许多开发人员在他们的个人机器上使用 git-svn 来弥补我们遇到的工作流问题（管理失败，但这是另一回事）。任何状况之下。它实际上是在平衡哪些功能集使您最有效率与组织需要的东西（例如集中式身份验证）。
集中式系统不一定会阻止您使用单独的分支进行开发。不需要代码库的单个真实副本，而是不同的开发人员或团队可以有不同的分支，可以存在遗留分支等。
它通常意味着存储库是集中管理的——但这对于拥有称职 IT 部门的公司来说通常是一个优势，因为这意味着只有一个地方可以备份，只有一个地方可以管理存储。