似乎很多人都读到了分布式版本控制,并且隐含地理解了为什么它对于开源开发来说是一件好事,许多分布式开发人员都是独立行事并且根据他们自己的选择而不是管理层的授权.但是从这种印象来看,许多人认为DVCS 仅在开源环境中有用; 他们无法看到它如何帮助组织发布专有产品,并且不会使其版本控制系统在外部可访问,或者它如何帮助单个开发人员.
如果企业选择使用分布式版本控制(如git,darcs或Mercurial)而不是集中版本控制(如CVS或Subversion),企业可以看到哪些好处?
这个论点似乎倒退了.
鉴于集中式修订控制系统只是分布式系统的众多用例之一,应用此类限制如何使公司受益?
我从经验中知道,当p4服务器变慢或中断或者你离它太远时,每个使用它的人都必须停止工作.
人们喜欢把"飞机"的论点当作一个稻草人,但我一直在那里真正重要的地方.对在互操作性事件现场或客户演示,我们将要建立的东西现在在有限的网络支持的环境和所有工作必须回来和我希望能够在我犯错误恢复.
我听过的两个论点对我不好:
无法获取所有代码并运行.
锁定
1号只是愚蠢的.也许它有点难以获得完整的历史记录(如果我不能,也没有修改控制系统),但是当谈到我们在这里谈论的那种恐惧时,我可以抓住最新版本和它同样危险.
2号真的好像试图使用错误的工具来完成工作.我以前从RCS用户获得抗CVS的论点,因为他们真的想你应该锁定每一个文件,每防止两个人的,我不知道,工作时间.
沟通是带外的.如果你有大的,不可合并的文件,我认为可以谈论它们.IMO,很多有这个问题的人都不想要一个版本控制系统,而是一个快照文件系统(zfs,9fs,Drop Box等......).
但总的来说,我不明白为什么人们甚至会问"我为什么要给我的开发人员提供更便宜,更快,更可靠,更强大的工具,并使他们更高效?" 各种问题.
首先,DVCS不会阻止集中式代码管理:您仍然可以将一个存储库设置为"引用"存储库,所有开发人员都可以从中进行管理.
因此,这里的好处(实际上是副作用)是通过数据复制进行的自然备份,同时保持中央代码库.
但真正的好处来自项目间的交叉开发:即当您需要"来自其他团队,来自其他项目"的开发时,为了您的工作向前发展:您可以轻松地将一个工作分支拉入您的工作中存储库(通过跟踪它),而不必等待它们正式在中央存储库中发布它.
这意味着即使存储库仅在内部复制(在公司内),您仍然可以获得DVCS的主要优势,即从本地和多样化的存储库中轻松跟踪,提取和合并分支,同时具有发布代码的主要基础对于开发生命周期的其余部分.
(每个集成,认证,预生产测试只会从发布到中央存储库的代码中运行).
人们还可以看到DVCS以这种方式管理一个自然的"清理"过程(只有"有效" - 至少是单元测试 - 才能发布到中央仓库),具有更清晰的历史记录(所有中间提交)可以留在本地存储库的主题分支).
我同意VonC,但是想补充一下(至少在git中)创建新的分支是很容易的,我可以轻松地处理实验代码或原型,我不一定要与其他存储库的用户共享.这有助于保持中央存储库的清洁(如果您使用它),我认为可以让开发人员尝试在他们冒险将实验代码放入中央存储库的系统中尝试的其他方式.
我还注意到,使用git在多个分支中工作是非常有效的,因为在分支之间交换很快,而且我不需要在单独的目录中一次检出多个分支.