版本控制与自动分发与依赖关系管理

Question

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

我没有任何经验distributed version control systems，但我觉得这个系统可以围绕一个DVCS建立。不同的库和不同任务的源文件将拥有自己的存储库。每个运行给定任务的节点都应该有该任务的回购实例。每个库的回购，至少有一个节点的任务使用，也应该出现在该节点上。开发人员将在节点上本地修改和编码代码，并使用DVCS技术将修改分发到其他节点上的回收站。

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

一些可能的方案：

1. 开发商push他们的改装，将有一个实例相同回购所有其他节点。 （但是，他们可能忘记/没有时间这样做。）
2. 节点自动pull从每一个其他远程回购的每一个变化，和update自己。 （但可能会有冲突。）
3. 对于每个回购，其中一个实例用作“参考”。开发人员push对这个实例的修改，以及每个其他节点都有一个实例自动从这里和update s本身。 （但具有参考实例的节点可能会停止。）

问题2 会是怎样处理的依赖关系的最佳方法是什么？

如果多个任务（或库）引用同一个库，并且必须修改引用的库，则一个或多个引用任务（或库）可能会停止工作（dependency hell）。最好是坚持使用最初提到的版本，并在正确测试后升级到新版本。也就是说，同一个源文件的多个版本应该出现在同一个回购站中，这似乎不可能。我是否必须为新版本的引用库创建新的branch？如果是，我应该如何升级转介回购协议？

谢谢你的帮助。

Answer 1

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

不协调感，共同点。VCS（SCM）是版本控制系统（源控制管理），即 - 轨道

• 在历史方面改变
• 大多
• 作为扁平阵列而不需要复杂的依赖关系（一些依赖性仍考虑）

你必须看到在工具another category - 配置管理软件，该手柄展开时，政策的，复杂的依赖关系，条件等本地

您可以得到一些迭代与DVCS来厘米，但是这将是艰苦的工作和现有的行之有效的工具，结果