On 09/04/10 13:54, Luke Kenneth Casson Leighton wrote: > On Sat, Sep 4, 2010 at 2:52 AM, Artur Skawina <art.08.09@xxxxxxxxx> wrote: >> Hmm, taking a few steps back, what is the expected usage of git-p2p? >> Note it's a bit of a trick question; what i'm really asking is what _else_, >> other than pulling/tracking Linus' kernel tree will/can be done with it? > > i'm _so_ glad you asked :) please note - for all of these i'm keenly > aware that GPG signing is required (and nicolas has pointed out that > you only need a 20-byte hash to be securely transferred by some OOB > mechanism) > > * distribution of large mailing lists and reduction of load on SMTP > * distributed wikis. there are lots of wikis now using git: ikiwiki > * distributed bugtrackers. the one that i know of which i believe > * of course there's source management for other projects other than > linux-2.6 :) I'm not sure that git fits well any of the above; it may be convenient to reuse git as it already exists and can be more or less easily plugged in, but it's probably not the best backend choice. The one that might map relatively closely to git is wikis, but there i'm not sure something more scalable wouldn't be better (eg how would wikipedia map onto git..) The one other use case for git-p2p that i can see is distributing the object store over a LAN. But it's really about a _remote_ object store, not so much a distributed one. IOW, having git-checkout trying to reach "/tmp/.git-unix/G0" and then any remote object store in addition to ".git/objects" would be very useful. But, do you actually want to spread the objects on _every_ developer desktop on the LAN? Wouldn't it much more make sense to have two or three dedicated "object servers", which would give you enough redundancy and, because of the higher chances of finding the required objects in cache, also perform better? For the case of an ad-hoc group of developers, the protocol described in my previous email would work well, they only need to find one peer and then can move objects back and forth in the swarm. One of the advantages that git-p2p could bring is better packing -- instead of everyone running git-repack with a limited window, each peer in the swarm could better use its resources by looking much deeper for the perfect delta candidate, but only for a subset of the objects, and then share the results with the rest. As a "git-repack -a -f" can eg shrink the gcc.git repo by ~15% (~100M) the savings could be noticeable. artur -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html