Do you use distributed version control?我想听听使用分布式版本控制(又名分布式修订版本控制，分散版本控制)的人们以及他们如何找到它。您在使用什么，Mercurial，Darcs，Git，Bazaar？您还在使用吗？如果您过去使用过客户端/服务器rcs，您发现它更好，更差还是有所不同？您能告诉我什么让我跳上潮流？或就此事出发，我也很想听听有负面经验的人的来信。 我目前正在寻找替换当前的源代码控制系统(Subversion)，这是解决此问题的动力。 我对与其他国家/地区的同事一起使用过的人特别感兴趣，在这些国家，您的机器可能无法同时打开，并且连接速度非常慢。 如果您不确定什么是分布式版本控制，请阅读以下几篇文章： 分布式版本控制简介 维基百科条目 我在工作中和个人项目中都一直使用Mercurial，对此我感到非常满意。我看到的优点是： 当然，像任何新系统一样，过渡期间也会有些痛苦。您必须与使用SVN时不同地考虑版本控制，但是总的来说，我认为这是非常值得的。 在我工作的地方，我们决定从SVN转到集市(在评估git和mercurial之后)。 Bazaar易于启动，使用简单的命令(不像git的140条命令) 我们看到的优点是能够创建本地分支并在不影响主版本的情况下对其进行处理。另外，即使没有网络访问也可以工作，因此进行差异比较快。 我喜欢bzr中的一个命令是扩展扩展。如果您开始在一个文件中处理两个逻辑上不同的代码段，并且只想提交一个代码段，则可以使用shelve扩展名在以后逐个搁置其他更改。在Git中，您可以在索引(临时区域)中进行操作，但是bzr具有更好的UI。 大多数人都不愿意移动，因为他们必须键入两个命令来提交和推送(bzr ci + bzr push)。对于他们来说，理解分支和合并的概念也很困难(没有人在svn中使用分支或合并分支)。 一旦了解，它将提高开发人员的生产力。直到所有人都知道，每个人之间的行为都会不一致。 我公司目前使用Subversion，CVS，Mercurial和git。 当我们五年前开始时，我们选择了CVS，但我们仍将其用于我们的主要开发和发行维护分支。但是，我们的许多开发人员都单独使用Mercurial作为拥有CVS分支机构(特别是合并它们)的痛苦的私有检查点的方法，并且我们开始将Mercurial用于一些最多有5个人的分支机构。我们很有可能在另一年内最终放弃CVS。我们对水银的使用已经有机增长。有些人甚至从未接触过它，因为他们对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设计是如此简单而优雅，我们将继续坚持下去。 在我的工作场所中，大约两个月前，我们从CVS转到了Git(我的大部分经验是使用Subversion)。虽然熟悉分布式系统涉及学习过程，但我发现Git在两个关键领域表现优异：工作环境的灵活性和合并。 我不必使用我们的VPN，甚至根本不需要网络连接，即可访问完整的版本控制功能。这意味着我可以在想法发生时尝试想法或执行大型重构，而无论碰巧在何处发生，而不必记住检查我已经建立的巨大提交，也不必担心弄得一团糟时无法恢复。 由于合并是在客户端执行的，因此与启动服务器端合并相比，合并速度更快且出错率更低。 我个人使用Mercurial源代码管理系统。我已经使用了一年多了。实际上，这是我第一次使用VSC。 我尝试过Git，但从未真正尝试过它，因为我发现它太合我的需要了。如果您是Subversion用户，Mercurial确实很容易上手，因为它与它共享许多命令。另外，我发现存储库的管理非常简单。 我有两种与他人共享代码的方式：
确实很容易使用，但功能非常强大。但总的来说，选择VSC确实取决于我们项目的需求... 我自己没有使用分布式源代码控制，但也许这些相关的问题和答案可以为您提供一些见解：
在大型项目(GHC)和许多小型项目中都使用过darcs。我与darcs有爱恨交织的关系。 优点：易于建立存储库。在存储库之间移动更改非常容易。非常容易克隆，并在单独的存储库中尝试"分支"。很容易在有条理的小组中进行"提交"。重命名文件和标识符非常容易。 缺点：没有历史观念-您无法恢复" 8月5日的状态"。我从来没有真正想过如何使用darcs返回到早期版本。
破坏交易的人：darcs无法扩展。我(和许多其他人)在使用darcs进行GHC时遇到了大麻烦。我试图将它挂在100％CPU使用率上9天 结论：darcs非常有用，如果您想要一种简单，轻巧的方法来避免自己为自己的业余爱好项目打针。但是，即使存在darcs 2中解决的一些性能问题，它仍然不是针对工业实力的东西。我不会真正相信darcs，除非吹牛的"补丁理论"比一些方程式和一些漂亮的图片要多得多。我希望看到在裁判现场发表的真实理论。已经过去了。 在关闭用于嵌入式系统开发的Sun工作站之前，我们使用的是Sun的TeamWare解决方案。 TeamWare是一个完全分发的解决方案，使用SCCS作为本地存储库文件修订系统，然后使用一组工具将其包装(通过分支重命名完成)以将合并操作返回到集中存储库，该集中存储库可以有很多。实际上，由于它是分布式的，因此实际上本身就没有主存储库(除非需要，否则按惯例除外)，并且所有用户都拥有自己的整个源代码树和修订版的副本。在"回送"操作期间，使用3向差异的合并工具可通过算法对内容进行分类，并使您可以合并来自不同开发人员的，随着时间推移而积累的更改。 在为我们的开发平台切换到Windows之后，我们最终切换到AccuRev。虽然AccuRev(因为它依赖于中央服务器)不是真正的分布式解决方案，但从逻辑上讲，工作流模型非常接近。在WareRev下，TeamWare会在每个客户端上完全分离所有副本，包括所有文件的所有修订版本，而在AccuRev下，此副本保存在中央数据库中，而本地客户端计算机仅具有平面文件的当前版本，可以在本地进行编辑。但是，可以通过与服务器的客户端连接来对这些本地副本进行版本控制，并与其他开发人员隐式创建的任何其他更改(即分支)完全分开地进行跟踪 我个人认为，TeamWare实现的分布式模型或AccuRev实现的某种混合模型优于完全集中的解决方案。造成这种情况的主要原因是，没有必要检出文件或由另一个用户锁定文件的想法。同样，用户不必创建或定义分支；工具会为您隐式执行此操作。当有较大的团队或不同的团队贡献或维护一组源文件时，这可以解决"工具生成的"锁定相关的冲突，并允许在开发人员级别上更加协调代码更改，而最终他们还是必须协调更改。从某种意义上说，分布式模型允许更细粒度的"锁定"，而不是集中式模型建立的过程细化锁定。 我的工作组正在使用Git，这已成为世界上所有的差异。我们正在使用SCCS和大量的csh脚本来管理在它们之间共享代码(无论如何尝试)的大型项目。
使用Git，子模块支持使很多事情变得容易，并且只需要最少的脚本即可。我们的发布工程工作已经进行了很长时间，因为分支易于维护和跟踪。能够廉价地分支和合并确实使在多个项目(合同)中维护单个资源集合变得相当容易，而在此之前，对典型事物流程的任何破坏都是非常非常昂贵的。我们还发现Git的脚本编写能力是一个巨大的优势，因为我们可以通过钩子或执行 有时，我们有时不得不在分布式的，非联网的站点上维护版本控制(在这种情况下，是断开的安全实验室)，而Git拥有相当流畅的处理机制(捆绑，基本克隆机制，格式化的补丁等)。 其中一些只是我们走出80年代初期并采用一些现代版本控制机制，但是Git在大多数领域"做到了"。 我不确定您要寻找的答案的范围，但是我们在Git方面的经验非常非常积极。 我真的很喜欢Git，尤其是在GitHub上。能够在本地提交和回滚真是太好了。挑选樱桃的合并虽然并不琐碎，但并不是很难，而且比Svn或CVS所能做的要先进得多。 由于许多原因，我强烈支持集中式源代码控制，但是我确实在项目中尝试了BitKeeper。也许在使用一种或另一种格式(Perforce，Subversion，CVS)的集中式模型多年之后，我才发现很难使用分布式源代码控制。 我的心态是，我们的工具永远不应妨碍实际工作；他们应该使工作更轻松。因此，经过几次头部撞击后，我保释。我建议在摇摆之前先与您的团队进行一些非常艰苦的测试，因为该模型与SCM世界中大多数开发人员可能习惯的模型完全不同。
我正在为Mercurial的家庭项目玩耍。到目前为止，我喜欢的是可以有多个存储库。如果我将笔记本电脑带到机舱，则我仍然拥有版本控制权，这与我在家运行CVS时不同。分支与 我已经使用集市了一段时间了并且喜欢它。细微的分支和合并会给应该使用分支的信心很大。 (我知道中央的vcs工具应该允许这样做，但是包括subversion在内的常见工具却不允许这样做)。 bzr支持许多不同的工作流程，从单独工作到作为集中存储库到完全分布式工作。每个分支(针对开发人员或功能部件)可以独立合并，因此可以在每个分支的基础上进行代码审查。 bzr还有一个很棒的插件(bzr-svn)，使您可以使用Subversion存储库。您可以复制svn仓库(最初需要一段时间，因为它会获取本地仓库的整个历史记录)。然后可以为不同功能创建分支。如果您想在功能的一半途中对主干进行快速修复，则可以创建一个额外的分支，在其中进行工作，然后合并回主干，从而使未完成的功能保持不变并位于主干之外。精彩。到目前为止，我的主要用途是防止颠覆。 请注意，我只在Linux上使用过它，并且大部分是从命令行使用的，尽管它可以在其他平台上很好地工作，并且具有诸如TortoiseBZR的GUI，并且在与IDE集成等方面正在进行很多工作。 在与中型团队的许多不同连接上，将Subversion与SourceForge和其他服务器配合使用，效果很好。 我在工作中与一位同事一起使用Git。不过，主要的存储库是SVN。我们经常不得不切换工作站，而Git使得从另一台机器上的本地存储库中提取更改变得非常容易。当我们作为一个团队在同一功能上工作时，合并我们的工作就很容易了。 git-svn桥有点怪，因为在检入SVN时，它将重写所有提交以添加其git-svn-id注释。这破坏了我同事的仓库之间合并的美好历史。我预测如果每个团队成员都将使用Git，我们将根本不会使用中央存储库。 您没有说要开发什么操作系统，但是Git的缺点是您必须使用命令行来获取所有功能。 Gitk是可视化合并历史记录的不错的gui，但是合并本身必须手动完成。 Git-Gui和Visual Studio插件还没有完善。 对于多站点和断开连接的场景，我们都使用分布式版本控制(Plastic SCM)。 1-多站点：如果您有较远的组，有时您可能无法依靠Internet连接，或者它的速度不够快，从而降低了开发人员的速度。然后，使用可以进行同步(Plastic来回复制分支)的独立服务器非常有用，并且可以加快处理速度。对于大多数公司来说，这可能是最常见的方案之一，因为它们中的大多数仍然关注"完全分布式"的做法，即每个开发人员都有自己的复制存储库。 2-断开连接(或根据需要分配为真正的分布式)：每个开发人员都有自己的存储库，该存储库与同级或中心位置来回复制。前往客户所在的位置或仅带着笔记本电脑回家，并且能够继续切换分支机构，签出和签入代码，查看历史记录，运行注释等非常方便，而无需访问远程"中心"服务器。然后，每当您回到办公室时，只需单击几下即可将更改(通常是分支)复制回去。 一直在使用darcs 2.1.0及其对我的项目非常有用。易于使用。爱樱桃采摘的变化。
Subversion不是分布式的，因此让我认为我需要一个Wikipedia链接，以防人们不确定我在说什么。 |
