No, it&#x27;s not the same as a distributed system with master&#x2F;slave nodes. The child nodes can function entirely in isolation from the parent. If you wanted to, you could treat another coworker&#x27;s node as your master and download&#x2F;upload to that. It&#x27;s usually easier to have a tree structure where the root is your master repo, its children are your build servers or whatever, and the leaves are development machines. But that&#x27;s entirely reconfigurable.<p>It&#x27;s not surprising at all that if you make a master repo at the root of the tree, and it goes down, then you can&#x27;t communicate it. But it doesn&#x27;t prohibit any communication between other nodes, or re-wiring the tree, and it definitely doesn&#x27;t inherently block development work on any of the other nodes.<p>It just so happens, though, that people&#x27;s build scripts and package managers like to refresh packages from the root and don&#x27;t handle failures modes of that operation very well. That&#x27;s the only place problems emerge - besides the obvious fact that if your public releases of software go through the root, and the root is down, then you can&#x27;t release until it&#x27;s up. But you could easily make a new root if you wanted to.