1

想象一个分布式软件系统,安装在一组几百台计算机(节点)上。节点负责自动运行计划任务。有数百个任务,每个任务计划在大约 5-10 个节点上运行。节点可能会停止数天,并且可能会从系统中删除。每个任务都由一个或多个源文件和特定于节点的配置文件定义。代码直接在节点上开发和测试(使用远程访问),因为只有这些节点配备了特殊的硬件并具有运行任务所需的网络上下文(构建单独的测试系统太昂贵了)。每个任务的源文件引用共享源文件(库),库可能引用其他库。任务和库的依赖树很复杂。

我对分布式版本控制系统没有任何经验,但我觉得这个系统可以围绕 DVCS 构建。不同的库和不同任务的源文件会有自己的存储库。每个运行给定任务的节点都应该有一个该任务的 repo 实例。每个节点的至少一个任务使用的每个库的存储库也应该存在于该节点上。开发人员将在节点上本地修改和commit编码,并使用 DVCS 技术将修改分发到其他节点上的 repos。

问题 #1 将代码更改分发到其他节点的最佳方法是什么?

一些可能的场景:

  1. 开发人员push对具有相同 repo 实例的每个其他节点进行修改。(但他们可能会忘记/没有时间这样做。)
  2. 节点会自动pull从每个其他远程存储库和update它们自己中进行每次更改。(但可能会有冲突。)
  3. 对于每个 repo,其中一个实例用作“参考”。开发人员push对这个实例的修改,以及具有实例的每个其他节点自动pull从这里和updates 本身。(但具有引用实例的节点可能会停止。)

问题 #2 处理依赖关系的最佳方法是什么?

如果多个任务(或库)引用同一个库,并且必须修改引用的库,则一个或多个引用任务(或库)可能会停止工作(依赖地狱)。最好还是坚持原来的版本,经过适当的测试升级到新版本。也就是说,同一源文件的多个版本应该存在于同一个 repo 中,这似乎是不可能的。我是否必须为branch引用库的新版本创建一个新版本?如果是,我应该如何升级推荐回购?

谢谢您的帮助。

4

1 回答 1

1

我对分布式版本控制系统没有任何经验,但我觉得这个系统可以围绕 DVCS 构建。

错误的感觉,共通。VCS(SCM)即版本控制系统(Source Control Management),即-track

  • 变化
  • 主要在历史方面
  • 作为没有复杂依赖的平面数组(仍然考虑到一些依赖)

您必须查看另一类工具 -配置管理软件,它可以本地处理部署、策略、复杂依赖项、条件等

可以使用 DVCS 对 CM 进行一些迭代,但这将是一项艰苦的工作,因此与现有完善的工具相去甚远

于 2012-10-24T19:03:56.010 回答