想象一个分布式软件系统，安装在数百台计算机（节点）上。节点负责自动运行计划的任务。有数百个任务，每个任务都安排在大约5-10个节点上运行。节点可能会停止几天，并且可以从系统中删除。每个任务都由一个或多个源文件和节点特定的配置文件定义。该代码是直接在节点上开发和测试的（使用远程访问），因为仅这些配备了特殊硬件，并且具有运行任务所需的网络上下文（构建单独的测试系统太贵了）。每个任务的源文件是指共享源文件（库），库可以参考其他库。任务和库的依赖树很复杂。
我没有分布式版本控制系统的任何经验，但是我认为该系统可以围绕DVC构建。不同的库和不同任务的源文件将具有自己的存储库。每个运行给定任务的节点都应具有该任务的存储库的实例。每个库的存储库（至少一个节点的一个任务）也应在该节点上存在。开发人员将在节点上本地修改和commit代码，并使用DVCS技术对其他节点进行修改。
问题＃1 将代码更改为其他节点的最佳方法是什么？
一些可能的情况：
- 开发人员
push对具有相同repo的所有其他节点进行修改。（但是他们可能会忘记/没有时间这样做。） - 节点自动
pull与其他所有遥控仓库和update本身的每一个更改。（但可能存在冲突。） - 对于每个存储库，其中一个实例用作"参考"。开发人员
push对此实例进行修改，并且所有其他节点具有一个实例，从这里自动pulls，并且updates本身。（但是具有参考实例的节点可能会停止。）
问题＃2 处理依赖项的最佳方法是什么？
如果多个任务（或库）是指同一库，并且必须修改引用的库，则一个或多个引用任务（或库）可能会停止工作（依赖关系地狱）。最好坚持最初的推荐版本，并在正确测试后升级到新版本。也就是说，在同一回购中应该存在多个版本的同一源文件，这似乎是不可能的。我是否必须为引用库的新版本创建一个新的branch？如果是，我应该如何升级推荐存储库？
谢谢您的帮助。
我没有分布式版本控制系统的经验， 但是我觉得该系统可以围绕DVC构建。
错误的感觉，共同。VCS（SCM）是版本控制系统（源控制管理），即轨道
- 更改
- 在历史方面主要是
- 作为没有复杂依赖的平坦数组（某些依赖性仍被考虑在内）
您必须在其他类别的工具上查看 - 配置管理软件，该软件处理部署，策略，复杂依赖，条件等本身
您可以通过DVC进行一些迭代，但结果将是现有良好工具的艰苦工作和苍白的外观