Re: usage for git-p2p (was: git pack/unpack over bittorrent - works!)

[Artur Skawina <art.08.09@gmail.com>]

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@gmail.com> 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