使用集中式版本控制系统与分布式版本控制系统(DVCS)的利弊是什么？我们是否在DVCS中遇到任何问题，并且如何防范这些问题？使讨论工具不可知且不可燃。

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

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

解决方案

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

可以确保不同的(地理)站点不在同一元素上工作。

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

要回答此答案的评论，我们真的希望该工具告诉我们谁拥有什么，然后与远程站点进行通信(通过电话，IM或者邮件)。
如果我们没有所有权机制...，我们将"交流"，但通常为时已晚；)(即：在同一分支中的一组相同文件上进行并发开发之后，提交可能会变得混乱)。

对我来说，这是关于个人品味的又一次讨论，要真正做到客观很难。我个人更喜欢Mercurial，而不是其他DVCS。我喜欢用与Mercurial相同的语言编写钩子，并且网络开销较小，这只是出于我自己的某些原因。

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

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

Distributed version control systems
  (DVCSs) solve different problems than
  Centralized VCSs.  Comparing them is
  like comparing hammers and
  screwdrivers.
  
  Centralized VCS systems are
  designed with the intent that there is
  One True Source that is Blessed, and
  therefore Good.  All developers work
  (checkout) from that source, and then
  add (commit) their changes, which then
  become similarly Blessed.  The only
  real difference between CVS,
  Subversion, ClearCase, Perforce,
  VisualSourceSafe and all the other
  CVCSes is in the workflow,
  performance, and integration that each
  product offers.
  
  Distributed VCS systems are
  designed with the intent that one
  repository is as good as any other,
  and that merges from one repository to
  another are just another form of
  communication.  Any semantic value as
  to which repository should be trusted
  is imposed from the outside by
  process, not by the software itself.
  
  The real choice between using one type
  or the other is organizational -- if
  your project or organization wants
  centralized control, then a DVCS is a
  non-starter.  If your developers are
  expected to work all over the
  country/world, without secure
  broadband connections to a central
  repository, then DVCS is probably your
  salvation.  If you need both, you're
  fsck'd.

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

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

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

To those who think distributed systems don't allow authoritative
  copies please note that there are plenty of places where distributed
  systems have authoritative copies, the perfect example is probably
  Linus' kernel tree. Sure lots of people have their own trees but
  almost all of them flow toward Linus' tree.
  
  That said I use to think that distributed SCM's were only useful for
  lots of developers doing different things but recently have decided
  that anything a centralized repository can do a distributed one can do
  better.
  
  For example, say you are a solo developer working on your own personal
  project. A centralized repository might be an obvious choice but
  consider this scenario. You are away from network access (on a plane,
  at a park, etc) and want to work on your project. You have your local
  copy so you can do work fine but you really want to commit because you
  have finished one feature and want to move on to another, or you found
  a bug to fix or whatever. The point is that with a centralized repo
  you end up either mashing all the changes together and commiting them
  in a non-logical changeset or you manually split them out later. 
  
  With a distributed repo you go on business as usual, commit, move on,
  when you have net access again you push to your "one true repo" and
  nothing changed.
  
  Not to mention the other nice thing about distributed repos: full
  history available always. You need to look at the revision logs when
  away from the net? You need to annotate the source to see how a bug
  was introduced? All possible with distributed repos.
  
  Please please don't believe that distributed vs centralized is about
  ownership or authoritative copies or anything like that. The reality
  is distributed is the next step in evolution of SCM's.

W. Craig Trader谈到了DVCS和CVCS：

If you need both, you're fsck'd.

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

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

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

和通常具有解决方法的一些缺点：

• 谁拥有最新版本？在CVCS中，干线通常具有最新版本，但是在DVCS中，它可能不是很明显。解决方法是使用行为规则，即项目中的开发人员必须达成协议，在该协议中，回购才能合并其工作。
• 悲观锁(即，在签出时锁定文件)通常是不可能的，因为DVCS中存储库之间可能会发生并发。版本控制中存在文件锁定的原因是，开发人员希望避免合并冲突。但是，锁定的缺点是放慢了开发速度，因为两个开发人员无法像使用长事务处理模型那样同时处理同一段代码，并且它也不是针对合并冲突的充分证据保证。无论版本控制如何，唯一有效的方法是解决大型合并冲突，即拥有良好的代码体系结构(如低耦合，高内聚性)并划分工作任务，以使它们对代码的影响很小(说起来容易做起来难) 。
• 在专有项目中，如果整个存储库都可以公开使用，那将是灾难性的。如果不满或者恶意的程序员掌握了克隆的存储库，则更是如此。对于专有企业而言，源代码泄漏是严重的痛苦。 DVCS使这一切变得简单，因为我们只需要克隆存储库，而某些CM系统(例如ClearCase)则试图限制该访问。但是，我认为，如果我们在公司文化中有足够多的功能失调，那么世界上没有任何版本控制可以防止源代码泄漏。

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

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

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

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

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

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

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

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

集中式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 ...
• 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社区中很流行。
• 化石SQLite

我使用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系统，我们可以轻松地使用中央服务器

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

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

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

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

因此，如果我们想使用DVCS，则它实际上不适用于管理不可合并的文件。

段落数量不匹配