你使用分布式版本控制吗？
我想听听使用分布式版本控制（又名分布式版本控制，分散版本控制）的人们以及他们如何find它。 你在用什么，Mercurial，Darcs，Git，Bazaar？ 你还在使用它吗？ 如果您以前使用过客户端/服务器rcs，您是否发现它更好，更糟或者只是不同？ 你能告诉我什么能让我跳上潮stream？ 或者跳出来，我会很乐意听到有负面经历的人。
我目前正在考虑replace我们当前的源代码控制系统（Subversion），这是这个问题的推动力。
我会特别感兴趣的是，在任何与其他国家的同事一起使用它的人，您的机器可能不会同时在线，而且您的连接速度很慢。
如果您不确定分布式版本控制是什么，这里有几篇文章：
介绍分布式版本控制
维基百科条目
我一直在工作和个人项目中使用Mercurial，我对此感到非常满意。 我看到的好处是：
- 本地版本控制。 有时我正在做一些事情，而且我想保留一个版本历史logging，但是我还没有准备好将它推送到中央存储库。 使用分布式VCS，我可以提交到我的本地回购，直到它准备好，没有分支。 这样，如果其他人做出我需要的更改，我仍然可以得到它们并将其整合到我的代码中。 当我准备好了，我把它推到服务器上。
- 更less的合并冲突。 他们还是会发生的，但是他们似乎不那么频繁，而且风险也不大，因为所有的代码都被签入到我的本地回购，所以即使我弄糟了合并，我也可以随时备份并重新执行。
- 作为分支单独回购。 如果我有几个发展载体在同一时间运行，我可以做我的回购几个克隆和独立开发每个function。 那样的话，如果有东西被刮掉或者滑倒了，我不必把东西拉出来。 当他们准备出发时，我就把它们合并在一起。
- 速度。 Mercurial的工作速度要快得多，主要是因为你们大部分的常规操作都是本地的。
当然，就像任何新制度一样，过渡期间也有一些痛苦。 你必须考虑版本控制的不同，当你使用SVN，但总的来说，我认为这是非常值得的。
在我工作的地方，我们决定从SVN转移到Bazaar（在评估git和mercurial之后）。 Bazaar很容易从简单的命令开始（不像git所拥有的140个命令）
我们看到的优势是能够创build本地分支并在不干扰主版本的情况下对其进行处理。 也可以在没有networking访问的情况下工作，比较更快。
我喜欢的bzr中的一个命令是搁置扩展。 如果您开始在单个文件中处理两个逻辑上不同的代码片段，并且只想提交一个代码片段，则可以使用搁置扩展来稍后搁置其他更改。 在Git中，您可以在索引（暂存区域）中执行相同的操作，但是bzr具有更好的用户界面。
大多数人不愿意移动，因为他们必须input两个命令来提交和推送（bzr ci + bzr push）。 他们也很难理解分支和合并的概念（没有人使用分支或合并到svn中）。
一旦你明白了，它会提高开发者的生产力。 直到每个人都明白，每个人都会有不一致的行为。
在我的工作场所，大约两个月前我们从CVS转到了Git（我的大部分经验都是在Subversion上）。 虽然熟悉分布式系统有一条学习曲线，但我发现Git在两个关键领域（工作环境的灵活性和合并）方面performance出色。
我不需要在我们的VPN上，或者甚至没有networking连接，就可以访问完整版本function。 这意味着我可以尝试想法，或者在冲动发生的时候进行大量的重构，而不必记得检查我已经build立起来的巨大承诺，或者担心在我搞乱时无法恢复。
因为合并是在客户端执行的，所以与启动服务器端合并相比，它们更快更容易出错。
我的公司目前使用Subversion，CVS，Mercurial和git。
当我们五年前开始的时候，我们select了CVS，我们在我们的主要开发和发布维护分支中仍然使用它。 然而，我们的许多开发人员使用Mercurial作为个人检查点的方式，而没有CVS分支的痛苦（特别是合并），我们开始将Mercurial用于一些拥有多达5人的分支机构。 我们有一个很好的机会，终于在一年后将CVS排除在外。 我们对Mercurial的使用已经有了增长。 有些人甚至从来没有碰过它，因为他们对CVS感到满意。 每个尝试过Mercurial的人都会感到高兴，没有太多的学习曲线。
Mercurial对我们来说非常合适，因为我们的（家庭酿造的）持续集成服务器可以监控开发商Mercurial存储库以及主线。 所以，人们提交到他们的仓库，让我们的持续集成服务器来检查它，然后发布变更集。 我们支持很多平台，因此做一个体面的手动检查是不可行的。 另一个胜利是合并往往很容易，而当他们很难得到所需要的信息时，你需要做好合并工作。 一旦有人得到合并版本的工作，他们可以推动他们的合并变更集，然后没有其他人不得不重复的努力。
最大的障碍是你需要重新连线你的开发人员和pipe理人员的大脑，使他们摆脱单一的线性分支模型。 最好的药物是Linus Torvalds ，如果你使用集中的SCM，告诉你你是愚蠢而丑陋的 。 良好的历史可视化工具将有所帮助，但我还不能满足于什么可用。
Mercurial和CVS对于使用Windows，Linux和Solaris的开发人员都适合我们，我注意到时区没有问题。 （真的，这不是太难，你只需要在内部使用纪元秒，我希望所有主要的SCM系统都能正确使用）。
经过相当大的努力，我们有可能将我们的主线CVS历史导入Mercurial。 如果人们不是故意将angular落案件引入我们的主线CVS历史作为testing历史迁移工具的一种方式，会更容易。 这包括将一些Mercurial分支合并到CVS历史logging中，所以该项目看起来像从第一天开始使用。
我们的芯片devise团队select了Subversion。 他们主要是离我的办公室八个时区，甚至在我们的办公室之间的一个相当好的专用线SUBversion结帐是痛苦的，但可行的。 集中式系统的一大优势是，您可以在不使所有分布式存储库巨大的情况下，检查大型二进制文件（例如供应商发行版）。
我们使用git来处理Linux内核。 一旦本地Windows版本成熟，Git会更适合我们，但是我认为Mercurial的devise非常简单和优雅，我们将坚持下去。
我自己不使用分布式源代码控制，但也许这些相关的问题和答案给你一些见解：
- 分布式源代码pipe理选项
- 为什么git比Subversion更好
我personnaly使用Mercurial源代码pipe理系统。 我已经使用了一年多一点了。 这实际上是我第一次使用VSC的经验。
我尝试了Git，但是从来没有真正推过它，因为我发现它太多了我所需要的。 如果你是一个Subversion用户，Mercurial很容易上手，因为它与它共享了很多命令。 另外我发现我的知识库的pipe理非常简单。
我有两种方式与人分享我的代码：
- 我与同事共享服务器，并为我们的项目保留主要的回购。
- 对于我所开发的一些OSS项目，我们使用Mercurial（hg export）创build了我们的工作补丁，并且项目的主要人员只需将它们应用于存储库（hg import）
真的很容易，但非常强大。 但一般来说，select一个VSC真的取决于我们项目的需要…
在closures用于embedded式系统开发的Sun工作站之前，我们使用了Sun的TeamWare解决scheme。 TeamWare是一个使用SCCS作为本地存储库文件修订版系统的完全分发解决scheme，然后用一组工具来处理合并操作（通过分支重命名完成）到可以有许多集中式存储库。 实际上，因为它是分布式的，所以实际上没有主存储库本身（除非按照惯例，否则所有用户都拥有自己的整个源代码树和修订版副本）。 在“放回”操作期间，使用3-way diffs的合并工具通过algorithm分类什么是什么，并允许您合并来自不同开发人员的随时间积累的更改。
切换到我们的开发平台的Windows后，我们结束了切换到AccuRev 。 虽然AccuRev因为依赖于集中式服务器而不是真正的分布式解决scheme，但从逻辑上来说，工作stream模型非常接近。 如果TeamWare在每个客户端上都有完全独立的副本（包括所有文件的所有修订版本），则在AccuRev下，这将在中央数据库中进行维护，本地客户端计算机只有当前版本的平面文件以便在本地进行编辑。 但是，这些本地副本可以通过客户端连接到服务器进行版本控制，并完全跟踪其他开发人员隐式创build的任何其他更改（即：分支）
就个人而言，我认为TeamWare实施的分布式模型或者AccuRev实现的这种混合模型比完全集中的解决scheme要优越。 这样做的主要原因是没有必要签出文件或文件被另一个用户locking的概念。 而且，用户不必创build或定义分支; 这些工具隐含地为你做这个。 当有更大的团队或不同的团队参与或维护一组源代码文件时，这将解决“工具生成”locking相关的冲突，并允许在开发者级别更多地协调代码更改，最终不得不协调更改。 从某种意义上说，分布式模型允许更细粒度的“locking”，而不是由集中式模型build立的过程locking。
在一个大项目（GHC）和大量的小项目中使用过darcs。 我与darcs有爱/恨的关系。
加号：非常容易设置存储库。 很容易在存储库之间移动变化。 很容易克隆和尝试在不同的存储库中的“分支机构”。 非常容易在小连贯的小组中做出“承诺”，这是合理的。 很容易重命名文件和标识符。
缺点：没有历史的概念—你不能在8月5日恢复“事态”。 我从来没有想过如何使用darcs回到早期版本。
交易断路器：darcs不会缩放。 我（和其他许多人）已经使用darcs与GHC发生了很大的麻烦。 我已经挂了9天CPU使用率100％，试图拉动3个月的变化。 去年夏天我遇到了一个不好的经历，那就是我花了两个星期的时间试图让darcs发挥作用，并最终用手将所有的变化重新放入一个原始的存储库中。
结论：如果你想要一个简单，轻量级的方式来保持自己的爱好项目在脚下射击自己，darcs是伟大的。 但即使在darcs 2中解决了一些性能问题，它仍然不是工业强度的东西。 我不会真的相信darcs，直到被大肆宣扬的“补丁理论”比一些方程式和一些漂亮的图片更有意义。 我想看一个真实的理论发表在一个审判场地。 已经过去了
我真的很喜欢Git，尤其是GitHub。 能够提交并在本地回滚是非常好的。 挑选合并虽然不是微不足道的，但并不难，而且比Svn或CVS能做的任何事都要先进得多。
我的团队在工作中使用Git，这在世界上都是不一样的。 我们正在使用SCCS和一堆csh脚本来pipe理相互之间共享代码的相当大且复杂的项目（无论如何）。
有了Git，子模块的支持使得很多东西变得简单，只需要最less的脚本。 由于分支机构易于维护和跟踪，因此我们的发布工程已经顺利进行。 能够廉价地进行分支和合并，使得在几个项目（合同）中维护一个单一的资源集合变得相当容易，而在之前，对典型的事务stream程的任何破坏都是非常非常昂贵的。 我们还发现Git的可读性是一个巨大的优势 ，因为我们可以通过钩子或通过脚本来定制它的行为. git-sh-setup . git-sh-setup ，而且它看起来不像以前那么多。
我们有时也会遇到这样的情况，我们必须在分布式，非联网的站点（在这种情况下是断开连接的安全实验室）上维护我们的版本控制，而且Git有相当平滑的处理机制（捆绑，基本的克隆机制，格式化补丁等）。
其中一些就是我们走出80年代初，采用了一些现代的版本控制机制，但Git在大部分领域“做得对”。
我不确定你正在寻找的答案的程度，但我们的Git经验非常非常积极。
使用Subversion与SourceForge和其他服务器通过与中等规模的团队进行多种不同的连接，并且工作得非常好。
我是很多原因的集中源代码控制的支持者，但是我曾经在一个项目上简单地尝试过BitKeeper。 也许在多年来以某种格式（Perforce，Subversion，CVS）使用集中式模型之后，我发现分布式源代码pipe理很难使用。
我的心态是，我们的工具不应妨碍实际的工作; 他们应该使工作更容易。 所以，经过几次冲击的经验，我保释。 我build议在摇摆船之前先与你的团队做一些非常耐用的testing，因为这个模型与大多数开发人员在SCM领域可能已经习惯的模型大不相同。
我已经用了一段时间的集市 ，并喜欢它。 微不足道的分支和合并使得他们有足够的信心使用分支机构。 （我知道中央vcs工具应该允许这个，但是包括颠覆在内的常用工具不允许这么做）。
bzr支持不同的工作stream程，从独奏，通过作为一个集中的存储库到完全分布。 对于能够独立合并的每个分支（对于开发者或特征），代码评论可以在每个分支基础上完成。
bzr也有一个很棒的插件（ bzr-svn ），允许你使用Subversion版本库。 你可以制作一个svn repo的副本（最初需要一段时间，因为它会为你的本地回购获取整个历史logging）。 然后你可以为不同的function分支。 如果你想在你的function中途快速修复树干，你可以制作一个额外的分支，在那里工作，然后合并回树干，让你的一半完成function不受干扰，并在树干外面。 精彩。 反对颠覆一直是我迄今为止的主要用途。
注意我只使用它在Linux上，主要来自命令行，虽然它意味着在其他平台上运行良好，有像TortoiseBZR的 GUI和大量的工作正在与IDE集成等。
我正在和Mercurial一起玩我的家庭项目。 到目前为止，我喜欢的是我可以有多个存储库。 如果我把我的笔记本电脑带到机舱，我仍然有版本控制，不像我在家里跑CVS。 分支就像hg clone一样简单，并在克隆上工作。
使用Subversion
Subversion不是分布式的，所以这让我觉得我需要一个维基百科链接，以防人们不知道我在说什么:)
一直在使用darcs 2.1.0和它的伟大的我的项目。 使用方便。 爱樱花采摘的变化。
我和其中一位同事一起在工作中使用Git。 不过，主要的存储库是SVN。 我们经常需要切换工作站，Git使得从另一台机器上的本地存储库中获取更改变得非常容易。 当我们作为一个团队在同一个function上工作时，合并我们的工作是毫不费力的。
git-svn的桥梁有一点不可思议，因为在检查SVN时，它会重写所有的提交以添加它的git-svn-id注释。 这破坏了我同事的回购合并的好的历史。 我预测，如果每个团队成员都使用Git，我们就不会使用中央存储库。
你没有说你开发的是什么，但是Git的缺点是你必须使用命令行才能获得所有的function。 Gitk是可视化合并历史的一个很好的GUI，但合并本身必须手动完成。 Git-Gui和Visual Studio插件还没有打磨。
我们使用分布式版本控制（ 塑料SCM ）为多站点和断开连接的情况。
1-多站点：如果你有遥远的团体，有时你不能依赖互联网连接，或者它不够快，并放慢开发。 然后有独立的服务器可以同步回来（塑料来回分支）是非常有用的，加快的东西。 这可能是公司最常见的情况之一，因为大多数公司仍然关心每个开发人员都拥有自己的复制存储库的“完全分布式”实践。
2-断开连接（如果您愿意，也可以是真正的分布式）：每个开发人员都有自己的存储库，可以与同事或中心位置来回复制。 使用笔记本电脑到客户的办公室非常方便，只需要用笔记本电脑回家，就可以切换分支机构，结账和登记代码，查看历史logging，运行注释等，而无需访问远程的“中央”服务器。 然后，无论何时回到办公室，只需点击几下即可复制您的更改（通常是分支机构）。
