3 ms·
You could also use the git protocol and a simple load-balanced pool of replicas that each pull from the main repo constantly. All push traffic would be routed
by 20after4 3y ago
You could also use the git protocol and a simple load-balanced pool of replicas that each pull from the main repo constantly. All push traffic would be routed to the central repo and all fetches would be routed to a random replica.
To do it in a decentralized fashion you could simply have a DNS pool with all of the known replicas and rely on round robin DNS (not great but better than a single point of failure)
Phabricator implements an interesting multi-master replication scheme with git that essentially keeps track of which node has the newest commit for a given HEAD, then edge nodes can automatically proxy incoming requests to the node with the latest change, or a random node if they are all in sync already.
- bayindirh 3y agoI think a Nordic broadcaster used "cascaded git" as a CDN. They pushed the content to a central repo, and as a hook, it pushed to four other repos. The repos had the same hook and it just fanned out, unattended. Pretty neat, if you ask me.
- teddyh 3y ago> To do it in a decentralized fashion you could simply have a DNS pool with all of the known replicas and rely on round robin DNS Using the new HTTPS DNS record¹ you could simply list all the servers in the DNS. 1. RFC 9460; discussion here a few months ago: <https://news.ycombinator.com/item?id=38420555 https://news.ycombinator.com/item?id=38420555>