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