我想听听使用分布式版本控制(即分布式版本控制,分散版本控制)以及他们如何找到它的人们的意见.你在用什么,Mercurial,Darcs,Git,Bazaar？你还在用吗？如果您以前使用过客户端/服务器rcs,您是否发现它更好,更糟或者只是不同？你能告诉我什么会让我跳上这个潮流？或者就此而言,我也有兴趣听取有负面经历的人的意见.
我目前正在考虑更换我们当前的源控制系统(Subversion),这是这个问题的推动力.
我特别感兴趣的是那些与其他国家的同事一起使用它的人,你的机器可能不会同时打开,而你的连接速度很慢.
如果你不确定分布式版本控制是什么,这里有几篇文章:
分布式版本控制简介
维基百科条目
我一直在工作和个人项目中使用Mercurial,我对它非常满意.我看到的优点是:
本地版本控制.有时我正在做一些事情,我想保留一个版本历史记录,但我还没准备好把它推到中央存储库.使用分布式VCS,我可以提交到我的本地仓库,直到它准备好,没有分支.这样,如果其他人进行了我需要的更改,我仍然可以获取它们并将它们集成到我的代码中.当我准备好了,我把它推到服务器上.
合并冲突减少.它们仍然会发生,但它们似乎不那么频繁,并且风险较小,因为所有代码都签入了我的本地仓库,所以即使我搞砸了合并,我总是可以备份并再次执行.
将回购分开作为分支.如果我有几个同时运行的开发向量,我可以只创建几个我的repo克隆并独立开发每个功能.这样,如果某些东西被废弃或滑落,我就不必拉出碎片了.当他们准备好了,我只是将它们合并在一起.
速度.Mercurial使用起来要快得多,主要是因为大多数常见操作都是本地操作.
当然,像任何新系统一样,在过渡期间会有一些痛苦.您必须考虑版本控制与使用SVN时的版本控制不同,但总的来说,我认为它非常值得.
在我工作的地方,我们决定从SVN搬到Bazaar(在评估git和mercurial之后).通过简单的命令(不像git拥有的140个命令),Bazaar很容易启动
我们看到的优势是能够创建本地分支并在其上工作而不会干扰主版本.也能够在没有网络访问的情况下工作,做差异更快.
我喜欢bzr中的一个命令是搁置扩展.如果您开始在单个文件中处理两个逻辑上不同的代码片段并且只想提交一个代码片段,则可以使用shelve扩展名来稍后搁置其他更改.在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混合的开发人员来说都很好,我注意到时区没有问题.(真的,这不是太难;你只是在内部使用epoch秒,我希望所有主要的SCM系统都能做到这一点).
通过相当大的努力,我们可以将主线CVS历史导入Mercurial.如果人们没有故意将角落案例引入我们的主线CVS历史记录中作为测试历史迁移工具的方法,那会更容易.这包括将一些Mercurial分支合并到CVS历史中,因此项目看起来就像从第一天开始使用一样.
我们的硅设计小组选择了Subversion.它们主要是离我办公室八个时区,即使在我们办公室之间的相当好的专线上,SUbversion结账很痛苦,但是可行.集中式系统的一大优势是,您可以检查大型二进制文件(例如供应商版本),而不会使所有分布式存储库变得庞大.
我们使用git来处理Linux内核.一旦原生Windows版本成熟,Git将更适合我们,但我认为Mercurial设计是如此简单和优雅,我们将坚持下去.
京公网安备 11010802040832号 | 京ICP备19059560号-6 