与分布式源代码控制的持续集成

分布式源代码控制和持续集成不是相互排斥的概念。事实上他们在一起玩得很好。

尽管dvc本质上是分布式的,但您仍将拥有一个中央存储库,它代表集中式版本系统中的传统“主干”。您不应该更改您的开发模型,因为您“发布”到您的中央存储库的更改的时间和内容。因为DVC不会强迫你去推动你的改变,所以在这方面你需要非常有纪律。

另一方面,DVCS使开发人员能够在其私有分支上执行更小的增量提交。这样做不仅使更改更容易遵循,而且最终也更容易合并。在添加特性或进行实验性更改时,本地提交尤其有用。或者当您需要中断对特性A的工作以修复非常重要的bug B时。

您应该在更改准备就绪时推送/发布更改。例如,我想重命名一个类。这将涉及50+个文件,即使只有几行。我使用重构工具进行重命名。

在一个集中式系统中,我现在必须决定这是否真的值得一次单独的提交,或者这是否是我目前正在处理的更大工作的一部分。出于经验,人们通常会选择第二种选择,因为你还不确定你是否希望这成为永久历史的一部分。

在分布式系统中,我可以在本地提交更改,我有一个明确的历史,将机械(重构)和功能代码更改分开。在这一点上,我不影响任何人。在我最终推出我的更改之前,我可能会很容易地修改这个决定。这将是一个干净的承诺自己那么。

本例中的问题是以下情况:假设我在本地分支或“延迟提交”上重命名该类。同时,有人将新代码提交到使用我刚刚重命名的类的trunk。合并我的名字会很麻烦。

A 持续集成 系统是一个工具(例如巡航控制),它每N分钟监视一次源代码存储库。

CI在任何方面都不依赖于您所使用的风投类型,无论是否是分布式的。

这其中有许多因素,有些与软件有关,有些与过程有关。

版本控制系统就是版本控制。回滚、分支和合并等能力,无论它们是集中的还是分散的,它们都有上下两面。风险投资本身并不能帮助您更好地编写代码或更好地运行项目,如果团队运行正常,它们会促进团队中的开发过程。换句话说,你可以搞砸就像皇室使用SVN或Mercurial你可以没有它。

使用现有的工具,Mercurial+Hudson,或者SVN和巡航控制的优势在于,你依靠的是人们的智慧和经验,他们可能在某个时候搞砸了,但却吸取了教训。但是,你不能做的是把它从盒子里拿出来,使用它,并期望它能在没有将你自己的项目过程添加到组合中的情况下工作。