想象一个分布式软件系统，安装在几百台计算机（节点）上。节点负责自动运行计划任务。有数百个任务，每个任务都安排在大约5-10个节点上运行。节点可能会停止数天，可能会从系统中删除。每个任务都由一个或多个源文件和特定于节点的配置文件定义。代码是直接在节点上开发和测试的（使用远程访问），因为只有这些代码配备了特殊的硬件并且具有运行任务所需的网络环境（构建单独的测试系统会太昂贵）。每个任务的源文件引用共享源文件（库），库可以引用其他库。任务和库的依赖树很复杂。
我对distributed version control systems没有任何经验，但我觉得这个系统可以围绕DVCS构建。不同的库和不同任务的源文件将拥有自己的存储库。运行给定任务的每个节点都应该具有该任务的repo的实例。由节点的至少一个任务使用的每个库的存储库也应该存在于该节点上。开发人员将在节点上本地修改和commit代码，并使用DVCS技术将修改分发到其他节点上的repos。
问题＃1 将代码更改分发到其他节点的最佳方法是什么？
一些可能的情况：
push对具有相同repo实例的每个其他节点的修改。 （但他们可能会忘记/没有时间这样做。）pull每个其他远程仓库的更改，update自己。 （但可能存在冲突。）push他们对此实例的修改，以及其他每个节点都自动pull来自update和branch s本身。 （但是具有引用实例的节点可能会停止。）问题＃2 处理依赖项的最佳方法是什么？
如果多个任务（或库）引用同一个库，并且必须修改引用的库，则一个或多个引用任务（或库）可能会停止工作（dependency hell）。最好坚持使用最初引用的版本，并在经过适当测试后升级到新版本。也就是说，同一个源文件的多个版本应该存在于同一个repo中，这似乎是不可能的。我是否必须为新版本的引用库创建新的{{1}}？如果是，我该如何升级转介回购？
感谢您的帮助。
答案 0 :(得分：1)
我对分布式版本控制系统没有任何经验， 但我觉得这个系统可以围绕DVCS构建。
错误的感觉，共同点。 VCS（SCM）是版本控制系统（源控制管理），即 - 轨道
您必须查看another category工具 - 配置管理软件，它们本地处理部署，策略，复杂依赖关系，条件等
你可以通过DVCS获得CM的一些迭代，但这将是一项艰苦的工作，并且结果显而易见的现有成熟工具