3 ms·

Next time you think about distributing git, you should take a look at the combination of jgit and a distributed key value store. A little while ago I spent a n

by eclark 10y ago

Next time you think about distributing git, you should take a look at the combination of jgit and a distributed key value store. A little while ago I spent a night and I was able to get a fully distributed git http server up and running. I used HBase and was able to get it most things working. That allows the only contention to be around refs. Everything else is well distributed and spread across as many machines as you need. Caching is handled on the key value store side, and the http server side. I didn't get to git gc work though.

jamesmiller5 10y ago
> That allows the only contention to be around refs. This is solved without modifying the git client using a distributed/shared lock wrapping the git-shell & git-hooks (pre-receive) . If you were to modify the git server behavior to say use epaxos, one could provide even better latency guaranties https://www.cs.cmu.edu/~dga/papers/epaxos-sosp2013.pdf https://www.cs.cmu.edu/~dga/papers/epaxos-sosp2013.pdf . I'm not sure about the GC operation though, did you use the DfsGarbageCollector that is part of Jgit? I thought that was provided as part of the DFS interface. http://download.eclipse.org/jgit/docs/jgit-2.0.0.201206130900-r/apidocs/org/eclipse/jgit/storage/dfs/DfsGarbageCollector.html http://download.eclipse.org/jgit/docs/jgit-2.0.0.20120613090...