我想听听使用分布式版本控制（又名分布式修订控制、分散式版本控制）的人以及他们是如何找到它的。你在用什么，Mercurial、Darcs、Git、Bazaar？你还在用吗？如果您过去使用过客户端/服务器 rcs，您会发现它更好、更差还是不同？你能告诉我什么能让我赶上潮流？或者就此而言，我很想听听有负面经历的人的意见。
我目前正在考虑更换我们当前的源代码控制系统（Subversion），这是这个问题的推动力。
我会对任何与其他国家的同事一起使用它的人特别感兴趣，因为您的机器可能不会同时打开，而且您的连接速度非常慢。
如果你不确定什么是分布式版本控制，这里有几篇文章：
我一直在工作和我自己的个人项目中使用 Mercurial，我对此非常满意。我看到的优点是：
当然，就像任何新系统一样，过渡期间也有一些痛苦。您必须以与使用 SVN 时不同的方式考虑版本控制，但总的来说，我认为这是非常值得的。
在我工作的地方，我们决定从 SVN 迁移到 Bazaar（在评估了 git 和 mercurial 之后）。Bazaar 很容易上手，命令简单（不像 git 的 140 个命令）
我们看到的优势是能够创建本地分支并在不影响主版本的情况下对其进行处理。也能够在没有网络访问的情况下工作，做差异更快。
我喜欢 bzr 中的一个命令是搁置扩展。如果您开始在一个文件中处理逻辑上不同的两段代码并且只想提交一段，则可以使用搁置扩展名在以后搁置其他更改。在 Git 中，您可以在索引（暂存区）中进行同样的操作，但 bzr 有更好的 UI。
大多数人都不愿意移动，因为他们必须输入两个命令来提交和推送（bzr ci + bzr push）。他们也很难理解分支和合并的概念（没有人使用分支或在 svn 中合并它们）。
一旦你理解了这一点，它将提高开发人员的生产力。直到每个人都明白这一点，每个人之间都会有不一致的行为。
大约两个月前，在我的工作场所，我们从 CVS 切换到 Git（我的大部分经验是使用 Subversion）。虽然熟悉分布式系统需要一段学习曲线，但我发现 Git 在两个关键领域更胜一筹：工作环境的灵活性和合并。
我不必使用我们的 VPN，甚至根本不需要网络连接，就可以访问完整的版本控制功能。这意味着当冲动来袭时，我可以在任何地方尝试想法或执行大型重构，而不必记住检查我已经建立的巨大提交，或者担心当我弄得一团糟时无法恢复。
因为合并是在客户端执行的，所以它们比启动服务器端合并要快得多且不易出错。
我的公司目前使用 Subversion、CVS、Mercurial 和 git。
当我们五年前开始时，我们选择了 CVS，我们仍然在我的部门将它用于我们的主要开发和发布维护分支。然而，我们的许多开发人员单独使用 Mercurial 作为一种拥有私有检查点的方式，而无需 CVS 分支（尤其是合并它们）的痛苦，并且我们开始将 Mercurial 用于一些最多有 5 人的分支。我们很有可能在另一年最终放弃 CVS。我们对 Mercurial 的使用有机地增长了；有些人甚至从未接触过它，因为他们对 CVS 很满意。每个尝试过 Mercurial 的人最终都对它感到满意，而没有太多的学习曲线。
Mercurial 对我们来说真正有用的是我们的（自制）持续集成服务器可以监控开发人员 Mercurial 存储库以及主线。因此，人们提交到他们的存储库，让我们的持续集成服务器对其进行检查，然后发布变更集。我们支持许多平台，因此进行相当程度的手动检查是不可行的。另一个胜利是合并通常很容易，当它们困难时，您可以获得做好合并所需的信息。一旦有人让合并的版本开始工作，他们就可以推送他们的合并变更集，然后其他人就不必重复这个工作了。
最大的障碍是您需要重新连接您的开发人员和经理的大脑，以便他们摆脱单一的线性分支模型。对此最好的药是一剂 Linus Torvalds 告诉你，如果你使用集中式 SCM ，你会变得愚蠢和丑陋。好的历史可视化工具会有所帮助，但我对可用的工具还不满意。
Mercurial 和 CVS 都适用于我们使用 Windows、Linux 和 Solaris 混合的开发人员，而且我注意到时区没有问题。（真的，这并不太难；您只需在内部使用纪元秒数，我希望所有主要的 SCM 系统都能做到这一点）。
通过相当多的努力，将我们的主线 CVS 历史导入 Mercurial 是可能的。如果人们没有故意在我们的主线 CVS 历史中引入极端案例作为测试历史迁移工具的一种方式，那将会更容易。这包括将一些 Mercurial 分支合并到 CVS 历史中，因此该项目看起来就像从第一天开始就在使用。
我们的芯片设计团队选择了 Subversion。它们主要离我的办公室有八个时区，甚至在我们办公室之间的一条相当好的专用线上 SUBversion 结帐是痛苦的，但可行。集中式系统的一大优势是您可以将大型二进制文件（例如供应商版本）签入其中，而无需使所有分布式存储库变得庞大。
我们使用 git 来处理 Linux 内核。一旦原生 Windows 版本成熟，Git 会更适合我们，但我认为 Mercurial 设计如此简单和优雅，我们会坚持下去。
我自己没有使用分布式源代码控制，但也许这些相关的问题和答案会给你一些见解：
我个人使用 Mercurial 源代码控制系统。我已经使用它一年多了。这实际上是我第一次体验 VSC。
我尝试了 Git，但从未真正投入使用，因为我发现它对于我需要的东西来说太多了。如果您是 Subversion 用户，Mercurial 真的很容易上手，因为它与它共享很多命令。另外，我发现我的存储库的管理非常容易。
我有 2 种方式与人分享我的代码：
真的很容易使用，但非常强大。但一般来说，选择VSC真的取决于我们项目的需求......
在我们关闭 Sun 工作站进行嵌入式系统开发之前，我们使用的是 Sun 的TeamWare解决方案。TeamWare 是一个完全分发的解决方案，它使用 SCCS 作为本地存储库文件修订系统，然后使用一组工具将其包装起来，以处理合并操作（通过分支重命名完成）回到可能有很多集中存储库的集中存储库。事实上，因为它是分布式的，所以实际上并没有主存储库（如果你想要的话，除非按照惯例），并且所有用户都有自己的整个源代码树和修订的副本。在“放回”操作期间，使用 3-way diffs 的合并工具在算法上整理出什么是什么，并允许您组合不同开发人员随时间累积的更改。
在为我们的开发平台切换到 Windows 之后，我们最终切换到了AccuRev。虽然 AccuRev，因为它依赖于一个集中式服务器，但并不是真正的分布式解决方案，从逻辑上讲，它与工作流模型非常接近。TeamWare 将在每个客户端拥有所有内容的完全独立副本，包括所有文件的所有修订，在 AccuRev 下，这将在中央数据库中维护，并且本地客户端计算机仅具有用于在本地编辑的平面文件当前版本。然而，这些本地副本可以通过与服务器的客户端连接进行版本控制，并完全独立于其他开发人员隐式创建的任何其他更改（即：分支）进行跟踪
就个人而言，我认为 TeamWare 实现的分布式模型或 AccuRev 实现的那种混合模型优于完全集中的解决方案。这样做的主要原因是没有必须签出文件或文件被其他用户锁定的概念。此外，用户不必创建或定义分支；这些工具隐含地为您执行此操作。当有更大的团队或不同的团队贡献或维护一组源文件时，这将解决“工具生成”与锁定相关的冲突，并允许在开发人员级别更多地协调代码更改，最终无论如何都必须协调更改。从某种意义上说，分布式模型允许更细粒度的“锁”，而不是由集中模型建立的粗粒度锁。
曾在大型项目 (GHC) 和许多小型项目中使用过 darcs。我与 darcs 有爱/恨的关系。
优点：非常容易设置存储库。在存储库之间移动更改非常容易。很容易在单独的存储库中克隆和尝试“分支”。在有意义的小型连贯小组中很容易做出“承诺”。很容易重命名文件和标识符。
缺点：没有历史概念——你无法恢复“8 月 5 日的状态”。我从来没有真正弄清楚如何使用 darcs 回到早期版本。
交易破坏者：darcs 无法扩展。我（和许多其他人）在使用 darcs 的 GHC 方面遇到了大麻烦。我已经让它以 100% 的 CPU 使用率挂起 9 天，试图进行 3 个月的更改。去年夏天我经历了一次糟糕的经历，我失去了两周的时间来尝试使 darcs 发挥作用，最终不得不将我所有的更改手动重放到一个原始存储库中。
结论：如果您想要一种简单、轻量级的方式来防止自己为您的爱好项目而自责，那么 darcs 非常棒。但即使在 darcs 2 中解决了一些性能问题，它仍然不适用于工业强度的东西。在吹嘘的“斑块理论”不仅仅是一些方程式和一些漂亮的图片之前，我不会真正相信 darcs。我想看到一个真正的理论发表在一个裁判场地。时间已经过去了。
我真的很喜欢 Git，尤其是 GitHub。能够在本地提交和回滚真是太好了。挑选合并虽然不是微不足道的，但也不是很困难，而且比任何 Svn 或 CVS 可以做的都先进得多。
我的工作小组正在使用 Git，这与世界不同。我们使用 SCCS 和一大堆 csh 脚本来管理它们之间共享代码的相当大而复杂的项目（无论如何都尝试过）。
使用 Git，子模块支持使很多事情变得容易，并且只需要最少的脚本。由于分支易于维护和跟踪，我们的发布工程工作已经进行了很长时间。能够廉价地分支和合并确实可以相当容易地跨多个项目（合同）维护单个源集合，而在此之前，对典型事物流程的任何中断都是非常非常昂贵的。我们还发现 Git 的可编写脚本能力是一个巨大的优势，因为我们可以通过钩子或脚本来自定义它的行为. git-sh-setup，而且它看起来不像以前那样一堆杂乱无章的东西。
我们有时也会遇到必须跨分布式、非联网站点（在本例中为断开连接的安全实验室）维护版本控制的情况，而 Git 具有非常顺利地处理这种情况的机制（捆绑包、基本克隆机制、格式化补丁等）。
其中一些只是我们走出 80 年代初并采用了一些现代版本控制机制，但 Git 在大多数领域“做得对”。
我不确定您正在寻找的答案范围，但我们在 Git 方面的经验非常非常积极。
将 Subversion 与 SourceForge 和其他服务器一起使用，通过许多不同的连接与中型团队合作，并且运行良好。
出于很多原因，我是集中式源代码控制的坚定支持者，但我确实在一个项目中短暂尝试过 BitKeeper。也许在以一种或另一种格式（Perforce、Subversion、CVS）使用集中模型多年之后，我发现分布式源代码控制很难使用。
我认为我们的工具永远不应该妨碍实际工作。他们应该使工作更容易。所以，在经历了几次头部撞击之后，我放弃了。我建议在摇摆船之前与您的团队进行一些非常严格的测试，因为该模型与大多数开发人员在 SCM 世界中可能习惯的模型非常不同。
我已经使用集市一段时间了，我很喜欢它。微不足道的分支和合并使人们对使用分支充满信心，因为它们应该被使用。（我知道中央 vcs 工具应该允许这样做，但包括 subversion 在内的常见工具不允许这样做）。
bzr 支持许多不同的工作流程，从单人到作为集中存储库工作到完全分布式。由于每个分支（对于开发人员或功能）都可以独立合并，因此可以在每个分支的基础上进行代码审查。
bzr 还有一个很棒的插件 ( bzr-svn ) 允许您使用 subversion 存储库。您可以制作 svn repo 的副本（最初需要一段时间，因为它会为您的本地 repo 获取整个历史记录）。然后，您可以为不同的功能创建分支。如果您想在功能进行到一半时对主干进行快速修复，您可以创建一个额外的分支，在其中工作，然后合并回主干，使您完成一半的功能保持不变并在主干之外。精彩的。到目前为止，反对颠覆一直是我的主要用途。
注意我只在 Linux 上使用过它，而且主要是在命令行中使用它，尽管它可以在其他平台上很好地工作，具有诸如TortoiseBZR之类的 GUI，并且在与IDE等集成方面正在进行大量工作。
我正在为我的家庭项目使用 Mercurial。到目前为止，我喜欢它的是我可以拥有多个存储库。如果我将笔记本电脑带到机舱，我仍然可以进行版本控制，这与我在家里运行 CVS 时不同。分支就像hg clone克隆一样简单。
使用颠覆
Subversion 没有分发，所以这让我觉得我需要一个维基百科链接，以防人们不确定我在说什么:)
一直在使用 darcs 2.1.0，它对我的项目非常有用。便于使用。爱樱桃采摘的变化。
我和我的一位同事一起在工作中使用 Git。不过，主存储库是 SVN。我们经常需要切换工作站，而 Git 使得从另一台机器上的本地存储库中提取更改变得非常容易。当我们作为一个团队在同一个功能上工作时，合并我们的工作是不费吹灰之力的。
git-svn 桥有点不稳定，因为当签入 SVN 时，它会重写所有提交以添加其 git-svn-id 注释。这破坏了我同事的回购和矿山之间合并的美好历史。我预测如果每个团队成员都使用 Git，我们根本不会使用中央存储库。
你没有说你是在什么操作系统上开发的，但是 Git 的缺点是你必须使用命令行来获取所有的特性。Gitk 是一个很好的可视化合并历史的 gui，但合并本身必须手动完成。Git-Gui 和 Visual Studio 插件还没有那么完善。
我们对多站点和断开连接的场景都使用分布式版本控制 ( Plastic SCM )。
1- 多站点：如果您有远程组，有时您不能依赖互联网连接，或者速度不够快并减慢开发人员的速度。然后拥有可以向后同步的独立服务器（塑料来回复制分支）非常有用并加快速度。这可能是公司最常见的场景之一，因为他们中的大多数人仍然关心“完全分布式”的做法，每个开发人员都有自己的复制存储库。
2- 断开连接（如果您愿意，也可以真正分布式）：每个开发人员都有自己的存储库，该存储库与他的同行或中央位置来回复制。去客户所在地或带着笔记本电脑回家都非常方便，并且可以继续切换分支、结帐和签入代码、查看历史记录、运行注释等，而无需访问远程“中央”服务器。然后，每当您回到办公室时，只需单击几下即可复制您的更改（通常是分支）。